Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp457555pxa; Fri, 21 Aug 2020 11:34:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0Z1qkcWjMU1LIIQSRTtzh5DI0QF6JeBRI3etyyoRkpzKe9Mz0JCflGRe745qvY7k5sp8F X-Received: by 2002:a17:906:38c7:: with SMTP id r7mr4398264ejd.118.1598034876290; Fri, 21 Aug 2020 11:34:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598034876; cv=none; d=google.com; s=arc-20160816; b=i6D6EXEacdBotmibnrl+1LLnLDVoz/deF4Sz5HnNre8ZDWkeNT/ChgP8NtL7AfeVrg s+00eI8y0py7gumnsuIEoAR7Ns1dsSzh8pcXS0tN7GqmthZ4vNgit/gWiUVSzZns8k74 o+FU3mTyuuV7ihOMeqHUS5JSDzKFYGyG0VFIGiwpZVXfBy+EScNVxBM4WDijaHMqOdHW SZTgNNW47m1nnaAizPXdWaVSGEIuSWpKE6f6tULOfXqNcKZwVWm9x4yZep79wVbTjG7f 1/kE785Wvzb7JiBPRYSpS4FLzRz6YEiT+A3YwKOpKWQ0Bl1ENeFpwzZ5SBQkiDBWn3dg yBFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:date:to:cc:from :subject:references:in-reply-to:content-transfer-encoding :mime-version; bh=BuwUHI6sz4DLMDIsDAC5vqKSSpxT9HU8QIcnRiGtfvk=; b=ghoP6quZtfV3yeno5YBrpKcTzx4wFKxk0vh1KF2t9Vsvzw6UKOF4IyxwwvSLyMwUUp maNrkNC0dnirNJqwBbG7oBzJ1Af4orDQQT7NcDX2jfJW25kw0/DYmU/t6nMNRmL4GfOp zHWfEKqFoCA3ewd4IJt82P39X+9jDxh62fr26d4gvvnunp3wtmerG4cnnhqFOy6lCjvB A5Icigqk3BjRH7wb7Yr5Voz68RN94ZABgriC5E1WWTEyf/0U4HHmDhov/8GVXTrvmX6B kbMWwJgD0cJd1+IhtBcyo39s1paOASYJe9VkGtakg1BnOGDz0Q1uEg/uV5oO66qC/L6E iWXA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g26si2321133edf.512.2020.08.21.11.34.13; Fri, 21 Aug 2020 11:34:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726673AbgHUSdf convert rfc822-to-8bit (ORCPT + 99 others); Fri, 21 Aug 2020 14:33:35 -0400 Received: from mail.fireflyinternet.com ([77.68.26.236]:54387 "EHLO fireflyinternet.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726666AbgHUSdc (ORCPT ); Fri, 21 Aug 2020 14:33:32 -0400 X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from localhost (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP (TLS) id 22202502-1500050 for multiple; Fri, 21 Aug 2020 19:33:12 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT In-Reply-To: <20190525054136.27810-8-baolu.lu@linux.intel.com> References: <20190525054136.27810-1-baolu.lu@linux.intel.com> <20190525054136.27810-8-baolu.lu@linux.intel.com> Subject: Re: [PATCH v4 07/15] iommu/vt-d: Delegate the dma domain to upper layer From: Chris Wilson Cc: ashok.raj@intel.com, jacob.jun.pan@intel.com, kevin.tian@intel.com, jamessewart@arista.com, tmurphy@arista.com, dima@arista.com, sai.praneeth.prakhya@intel.com, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Lu Baolu To: David Woodhouse , Joerg Roedel , Lu Baolu Date: Fri, 21 Aug 2020 19:33:10 +0100 Message-ID: <159803479017.29194.1359332295829225843@build.alporthouse.com> User-Agent: alot/0.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Lu Baolu (2019-05-25 06:41:28) > This allows the iommu generic layer to allocate a dma domain and > attach it to a device through the iommu api's. With all types of > domains being delegated to upper layer, we can remove an internal > flag which was used to distinguish domains mananged internally or > externally. I'm seeing some really strange behaviour with this patch on a 32b Skylake system (and still present on mainline). Before this patch everything is peaceful and appears to work correctly. Applying this patch, and we fail to initialise the GPU with a few DMAR errors reported, e.g. [ 20.279445] DMAR: DRHD: handling fault status reg 3 [ 20.279508] DMAR: [DMA Read] Request device [00:02.0] fault addr 8900a000 [fault reason 05] PTE Write access is not set Setting an identity map for the igfx made the DMAR errors disappear, but the GPU still failed to initialise. There's no difference in the DMAR configuration dmesg between working and the upset patch. And the really strange part is that switching to a 64b kernel with this patch, it's working. Any suggestions on what I should look for? -Chris