From: Lu Baolu <baolu.lu@linux.intel.com> To: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org, David Woodhouse <dwmw2@infradead.org>, iommu@lists.linux-foundation.org Subject: Re: [PATCH 1/4] iommu/vt-d: Disable superpage for Geminilake igfx Date: Tue, 13 Jul 2021 09:34:09 +0800 [thread overview] Message-ID: <dcc41a8e-8076-5798-75da-1c356756d9b0@linux.intel.com> (raw) In-Reply-To: <YOxkBeICOosZcVEY@intel.com> On 7/12/21 11:47 PM, Ville Syrjälä wrote: > On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote: >> On 7/10/21 12:47 AM, Ville Syrjala wrote: >>> From: Ville Syrjälä<ville.syrjala@linux.intel.com> >>> >>> While running "gem_exec_big --r single" from igt-gpu-tools on >>> Geminilake as soon as a 2M mapping is made I tend to get a DMAR >>> write fault. Strangely the faulting address is always a 4K page >>> and usually very far away from the 2M page that got mapped. >>> But if no 2M mappings get used I can't reproduce the fault. >>> >>> I also tried to dump the PTE for the faulting address but it actually >>> looks correct to me (ie. definitely seems to have the write bit set): >>> DMAR: DRHD: handling fault status reg 2 >>> DMAR: [DMA Write] Request device [00:02.0] PASID ffffffff fault addr 7fa8a78000 [fault reason 05] PTE Write access is not set >>> DMAR: fault 7fa8a78000 (level=1) PTE = 149efc003 >>> >>> So not really sure what's going on and this might just be full on duct >>> tape, but it seems to work here. The machine has now survived a whole day >>> running that test whereas with superpage enabled it fails in less than >>> a minute usually. >>> >>> TODO: might be nice to disable superpage only for the igfx iommu >>> instead of both iommus >> If all these quirks are about igfx dedicated iommu's, I would suggest to >> disable superpage only for the igfx ones. > Sure. Unfortunately there's no convenient mechanism to do that in > the iommu driver that I can immediately see. So not something I > can just whip up easily. Since you're actually familiar with the > driver maybe you can come up with a decent solution for that? > How about something like below? [no compile, no test...] diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 1131b8efb050..2d51ef288a9e 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -338,6 +338,7 @@ static int intel_iommu_strict; static int intel_iommu_superpage = 1; static int iommu_identity_mapping; static int iommu_skip_te_disable; +static int iommu_skip_igfx_superpage; #define IDENTMAP_GFX 2 #define IDENTMAP_AZALIA 4 @@ -652,6 +653,27 @@ static bool domain_update_iommu_snooping(struct intel_iommu *skip) return ret; } +static bool domain_use_super_page(struct dmar_domain *domain) +{ + struct dmar_drhd_unit *drhd; + struct intel_iommu *iommu; + bool ret = true; + + if (!intel_iommu_superpage) + return false; + + rcu_read_lock(); + for_each_active_iommu(iommu, drhd) { + if (drhd->gfx_dedicated && iommu_skip_igfx_superpage) { + ret = false; + break + } + } + rcu_read_unlock(); + + return ret; +} + static int domain_update_iommu_superpage(struct dmar_domain *domain, struct intel_iommu *skip) { @@ -659,7 +681,7 @@ static int domain_update_iommu_superpage(struct dmar_domain *domain, struct intel_iommu *iommu; int mask = 0x3; - if (!intel_iommu_superpage) + if (!domain_use_super_page(domain)) return 0; /* set iommu_superpage to the smallest common denominator */ @@ -5656,6 +5678,14 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1632, quirk_iommu_igfx); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163A, quirk_iommu_igfx); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx); +static void quirk_skip_igfx_superpage(struct pci_dev *dev) +{ + pci_info(dev, "Disabling IOMMU superpage for graphics on this chipset\n"); + iommu_skip_igfx_superpage = 1; +} + +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x3184, quirk_skip_igfx_superpage); + static void quirk_iommu_rwbf(struct pci_dev *dev) { if (risky_device(dev)) Best regards, baolu _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com> To: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org, David Woodhouse <dwmw2@infradead.org>, iommu@lists.linux-foundation.org, baolu.lu@linux.intel.com Subject: Re: [Intel-gfx] [PATCH 1/4] iommu/vt-d: Disable superpage for Geminilake igfx Date: Tue, 13 Jul 2021 09:34:09 +0800 [thread overview] Message-ID: <dcc41a8e-8076-5798-75da-1c356756d9b0@linux.intel.com> (raw) In-Reply-To: <YOxkBeICOosZcVEY@intel.com> On 7/12/21 11:47 PM, Ville Syrjälä wrote: > On Mon, Jul 12, 2021 at 07:23:07AM +0800, Lu Baolu wrote: >> On 7/10/21 12:47 AM, Ville Syrjala wrote: >>> From: Ville Syrjälä<ville.syrjala@linux.intel.com> >>> >>> While running "gem_exec_big --r single" from igt-gpu-tools on >>> Geminilake as soon as a 2M mapping is made I tend to get a DMAR >>> write fault. Strangely the faulting address is always a 4K page >>> and usually very far away from the 2M page that got mapped. >>> But if no 2M mappings get used I can't reproduce the fault. >>> >>> I also tried to dump the PTE for the faulting address but it actually >>> looks correct to me (ie. definitely seems to have the write bit set): >>> DMAR: DRHD: handling fault status reg 2 >>> DMAR: [DMA Write] Request device [00:02.0] PASID ffffffff fault addr 7fa8a78000 [fault reason 05] PTE Write access is not set >>> DMAR: fault 7fa8a78000 (level=1) PTE = 149efc003 >>> >>> So not really sure what's going on and this might just be full on duct >>> tape, but it seems to work here. The machine has now survived a whole day >>> running that test whereas with superpage enabled it fails in less than >>> a minute usually. >>> >>> TODO: might be nice to disable superpage only for the igfx iommu >>> instead of both iommus >> If all these quirks are about igfx dedicated iommu's, I would suggest to >> disable superpage only for the igfx ones. > Sure. Unfortunately there's no convenient mechanism to do that in > the iommu driver that I can immediately see. So not something I > can just whip up easily. Since you're actually familiar with the > driver maybe you can come up with a decent solution for that? > How about something like below? [no compile, no test...] diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 1131b8efb050..2d51ef288a9e 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -338,6 +338,7 @@ static int intel_iommu_strict; static int intel_iommu_superpage = 1; static int iommu_identity_mapping; static int iommu_skip_te_disable; +static int iommu_skip_igfx_superpage; #define IDENTMAP_GFX 2 #define IDENTMAP_AZALIA 4 @@ -652,6 +653,27 @@ static bool domain_update_iommu_snooping(struct intel_iommu *skip) return ret; } +static bool domain_use_super_page(struct dmar_domain *domain) +{ + struct dmar_drhd_unit *drhd; + struct intel_iommu *iommu; + bool ret = true; + + if (!intel_iommu_superpage) + return false; + + rcu_read_lock(); + for_each_active_iommu(iommu, drhd) { + if (drhd->gfx_dedicated && iommu_skip_igfx_superpage) { + ret = false; + break + } + } + rcu_read_unlock(); + + return ret; +} + static int domain_update_iommu_superpage(struct dmar_domain *domain, struct intel_iommu *skip) { @@ -659,7 +681,7 @@ static int domain_update_iommu_superpage(struct dmar_domain *domain, struct intel_iommu *iommu; int mask = 0x3; - if (!intel_iommu_superpage) + if (!domain_use_super_page(domain)) return 0; /* set iommu_superpage to the smallest common denominator */ @@ -5656,6 +5678,14 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1632, quirk_iommu_igfx); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163A, quirk_iommu_igfx); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D, quirk_iommu_igfx); +static void quirk_skip_igfx_superpage(struct pci_dev *dev) +{ + pci_info(dev, "Disabling IOMMU superpage for graphics on this chipset\n"); + iommu_skip_igfx_superpage = 1; +} + +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x3184, quirk_skip_igfx_superpage); + static void quirk_iommu_rwbf(struct pci_dev *dev) { if (risky_device(dev)) Best regards, baolu _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-07-13 1:36 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-09 16:47 [PATCH 0/4] iommu/vt-d: Disable igfx iommu superpage on bxt/skl/glk Ville Syrjala 2021-07-09 16:47 ` [Intel-gfx] " Ville Syrjala 2021-07-09 16:47 ` [PATCH 1/4] iommu/vt-d: Disable superpage for Geminilake igfx Ville Syrjala 2021-07-09 16:47 ` [Intel-gfx] " Ville Syrjala 2021-07-11 23:23 ` Lu Baolu 2021-07-11 23:23 ` [Intel-gfx] " Lu Baolu 2021-07-12 15:47 ` Ville Syrjälä 2021-07-12 15:47 ` [Intel-gfx] " Ville Syrjälä 2021-07-13 1:34 ` Lu Baolu [this message] 2021-07-13 1:34 ` Lu Baolu 2021-07-13 20:30 ` Ville Syrjälä 2021-07-13 20:30 ` [Intel-gfx] " Ville Syrjälä 2021-07-14 1:31 ` Lu Baolu 2021-07-14 1:31 ` [Intel-gfx] " Lu Baolu 2021-07-09 16:47 ` [PATCH 2/4] iommu/vt-d: Disable superpage for Broxton igfx Ville Syrjala 2021-07-09 16:47 ` [Intel-gfx] " Ville Syrjala 2021-07-09 16:47 ` [PATCH 3/4] iommu/vt-d: Disable superpage for Skylake igfx Ville Syrjala 2021-07-09 16:47 ` [Intel-gfx] " Ville Syrjala 2021-07-09 16:47 ` [PATCH 4/4] drm/i915/fbc: Allow FBC + VT-d on SKL/BXT Ville Syrjala 2021-07-09 16:47 ` [Intel-gfx] " Ville Syrjala 2021-07-09 18:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for iommu/vt-d: Disable igfx iommu superpage on bxt/skl/glk Patchwork 2021-07-09 18:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-07-10 12:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork 2021-07-13 1:59 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for iommu/vt-d: Disable igfx iommu superpage on bxt/skl/glk (rev2) Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=dcc41a8e-8076-5798-75da-1c356756d9b0@linux.intel.com \ --to=baolu.lu@linux.intel.com \ --cc=dwmw2@infradead.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=iommu@lists.linux-foundation.org \ --cc=ville.syrjala@linux.intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.