[PATCH] iommu/vt-d: only attempt to cleanup svm page request irq if one assigned

Only try to clean up the svm page request irq if one has been assigned. Also clear pr_irq in the error path if irq request fails. Signed-off-by: Jerry Snitselaar <jsnit...@redhat.com> --- drivers/iommu/intel-svm.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff

[PATCH] iommu/vt-d: clean up pr_irq if request_threaded_irq fails

a7 81 31 c0 e8 4c 37 fa ff <0f> ff 48 8b 34 24 4c 89 ef e 8 0e 4c 68 00 49 8b 46 40 48 8b 80 [0.669688] ---[ end trace 58a470248700f2fc ]--- Cc: Alex Williamson <alex.william...@redhat.com> Cc: Joerg Roedel <j...@8bytes.org> Cc: Ashok Raj <ashok....@intel.com> Si

Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

On Mon Apr 16 18, Jacob Pan wrote: From: "Liu, Yi L" When an SVM capable device is assigned to a guest, the first level page tables are owned by the guest and the guest PASID table pointer is linked to the device context entry of the physical IOMMU. Host IOMMU driver

Re: source-id verification failures

On Fri Oct 05 18, Raj, Ashok wrote: On Thu, Oct 04, 2018 at 03:07:46PM -0700, Jacob Pan wrote: On Thu, 4 Oct 2018 13:57:24 -0700 Jerry Snitselaar wrote: > On Thu Oct 04 18, Joerg Roedel wrote: > >Hi Jerry, > > > >thanks for the report. > > > >On Tue, Oct 02

Re: source-id verification failures

On Fri Oct 05 18, Jacob Pan wrote: On Thu, 4 Oct 2018 13:57:24 -0700 Jerry Snitselaar wrote: > >On Tue, Oct 02, 2018 at 10:25:29AM -0700, Jerry Snitselaar wrote: >> I've been trying to track down a problem where an hp dl380 gen8 >> with a Cavium QLogic BR-1860 Fabric Adapter

source-id verification failures

I've been trying to track down a problem where an hp dl380 gen8 with a Cavium QLogic BR-1860 Fabric Adapter is getting source-id verification failures when running dhclient against that interface. This started showing up when I backported the iova deferred flushing patches. So far this has only

[PATCH] iommu: amd: call free_iova_fast with pfn in map_sg

In the error path of map_sg, free_iova_fast is being called with address instead of the pfn. This results in a bad value getting into the rcache, and can result in hitting a BUG_ON when iova_magazine_free_pfns is called. Cc: Joerg Roedel Cc: Suravee Suthikulpanit Signed-off-by: Jerry Snitselaar

Question about out_unmap section of map_sg in amd_iommu.c

out_unmap: pr_err("%s: IOMMU mapping error in map_sg (io-pages: %d)\n", dev_name(dev), npages); for_each_sg(sglist, s, nelems, i) { int j, pages = iommu_num_pages(sg_phys(s), s->length, PAGE_SIZE); for (j = 0; j < pages;

[PATCH] iommu/amd: unmap all mapped pages in error path of map_sg

page. Fix the condition, so it breaks out of the loop only after all the mapped pages have been unmapped. Fixes: 80187fd39dcb ("iommu/amd: Optimize map_sg and unmap_sg") Cc: Joerg Roedel Signed-off-by: Jerry Snitselaar --- drivers/iommu/amd_iommu.c | 2 +- 1 file changed, 1 insertion(+),

Re: [PATCH] iommu: amd: call free_iova_fast with pfn in map_sg

On Thu Jan 17 19, Jerry Snitselaar wrote: In the error path of map_sg, free_iova_fast is being called with address instead of the pfn. This results in a bad value getting into the rcache, and can result in hitting a BUG_ON when iova_magazine_free_pfns is called. Cc: Joerg Roedel Cc: Suravee

Re: [PATCH v2] iommu/amd: Reserve exclusion range in iova-domain

On Fri Mar 29 19, Joerg Roedel wrote: From: Joerg Roedel If a device has an exclusion range specified in the IVRS table, this region needs to be reserved in the iova-domain of that device. This hasn't happened until now and can cause data corruption on data transfered with these devices.

Re: [PATCH v2] iommu/amd: Reserve exclusion range in iova-domain

e0741f72dc..87965e4d9647 100644 --- a/drivers/iommu/amd_iommu_types.h +++ b/drivers/iommu/amd_iommu_types.h @@ -374,6 +374,8 @@ #define IOMMU_PROT_IR 0x01 #define IOMMU_PROT_IW 0x02 +#define IOMMU_UNITY_MAP_FLAG_EXCL_RANGE(1 << 2) + /* IOMMU capabilities */ #defi

[PATCH] iommu/amd: print reason for iommu_map_page failure in map_sg

Since there are multiple possible failures in iommu_map_page it would be useful to know which case is being hit when the error message is printed in map_sg. While here, fix up checkpatch complaint about using function name in a string instead of __func__. Cc: Joerg Roedel Signed-off-by: Jerry

Re: [PATCH 2/6] iommu/amd: Remove amd_iommu_devtable_lock

___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 3/6] iommu/amd: Take domain->lock for complete attach/detach path

_ON(!entry->domain); - __detach_device(entry); + do_detach(entry); } + + spin_unlock_irqrestore(>lock, flags); } static void protection_domain_free(struct protection_domain *domain) -- 2.17.1 ___ iommu mailing list iommu@lists.

Re: [PATCH 5/6] iommu/amd: Lock dev_data in attach/detach code paths

in; /* Domain the device is bound to */ -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu Reviewed-by: Jerry Snitselaar ___ iommu ma

Re: [PATCH 1/6] iommu/amd: Remove domain->updated

complete domain flush required */ unsigned dev_cnt; /* devices assigned to this domain */ unsigned dev_iommu[MAX_IOMMUS]; /* per-IOMMU reference count */ }; -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org ht

Re: [PATCH 4/6] iommu/amd: Check for busy devices earlier in attach_device()

ed kernel -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-f

Re: [PATCH 6/6] iommu/amd: Lock code paths traversing protection_domain->dev_list

(>lock, flags); } static void amd_iommu_iotlb_sync(struct iommu_domain *domain, -- 2.17.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu Reviewed-by: Jerry Snitselaar __

Re: [PATCH 0/6] iommu/amd: Locking Fixes

On Wed Sep 25 19, Joerg Roedel wrote: Hi, here are a couple of fixes for the amd iommu driver to fix a few locking issues around protection-domains. Main problem was that some traversals of ->dev_list were not locked in any form, causing potential race conditions. But there are more issues

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Tue Dec 03 19, Lu Baolu wrote: Hi, On 12/3/19 12:13 AM, Jerry Snitselaar wrote: On Mon Dec 02 19, Jerry Snitselaar wrote: On Mon Dec 02 19, Lu Baolu wrote: Hi, On 12/2/19 2:34 PM, Jerry Snitselaar wrote: We are seeing DMAR PTE read access not set errors when booting a kernel

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Thu Dec 05 19, Lu Baolu wrote: Hi, On 12/5/19 4:53 AM, Jerry Snitselaar wrote: Attaching console output (can't get to a point to actually log in) and config that is used to build that kernel. [...] [ 21.969477] pci :00:00.0: Adding to iommu group 0 [ 21.971390] pci :00:01.0

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Thu Dec 05 19, Lu Baolu wrote: Hi, On 12/5/19 10:25 AM, Jerry Snitselaar wrote: It seems that iommu pci bus probe didn't enumerate device [01:00.2] and [02:00.0], the corresponding context entries were not setup. Hence dma fault generated when devices access the memory. Do these two

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Sat Dec 07 19, Lu Baolu wrote: Hi Jerry, On 12/6/19 3:24 PM, Jerry Snitselaar wrote: On Fri Dec 06 19, Lu Baolu wrote: [snip] Can you please try below change? Let's check whether the afending address has been mapped for device 01.00.2. $ git diff diff --git a/drivers/iommu/iommu.c b

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Fri Dec 06 19, Jerry Snitselaar wrote: On Sat Dec 07 19, Lu Baolu wrote: Hi Jerry, On 12/6/19 3:24 PM, Jerry Snitselaar wrote: On Fri Dec 06 19, Lu Baolu wrote: [snip] Can you please try below change? Let's check whether the afending address has been mapped for device 01.00.2. $ git

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Tue Dec 10 19, Lu Baolu wrote: Hi, On 12/10/19 1:18 PM, Jerry Snitselaar wrote: On Mon Dec 09 19, Jerry Snitselaar wrote: [snip] A call to iommu_map is failing. [   36.686881] pci :01:00.2: iommu_group_add_device: calling iommu_group_create_direct_mappings [   36.689843] pci :01

Re: [PATCH 1/1] iommu/vt-d: Fix dmar pte read access not set error

On Thu Dec 12 19, Lu Baolu wrote: Hi, On 12/12/19 9:49 AM, Jerry Snitselaar wrote: On Wed Dec 11 19, Lu Baolu wrote: If the default DMA domain of a group doesn't fit a device, it will still sit in the group but use a private identity domain. When map/unmap/iova_to_phys come through iommu API

Re: [PATCH] iommu/vt-d: Set ISA bridge reserved region as relaxable

vers such as vfio. Fixes: d850c2ee5fe2 ("iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions") Cc: sta...@vger.kernel.org # v5.3+ Link: https://lore.kernel.org/linux-iommu/20191211082304.2d4fa...@x1.home Reported-by: cprt Tested-by: cprt Signed-off-by: Alex W

Re: [PATCH 1/1] iommu/vt-d: Fix dmar pte read access not set error

On Fri Dec 13 19, Lu Baolu wrote: Hi, On 12/13/19 8:30 AM, Jerry Snitselaar wrote: On Thu Dec 12 19, Lu Baolu wrote: Hi, On 12/12/19 9:49 AM, Jerry Snitselaar wrote: On Wed Dec 11 19, Lu Baolu wrote: If the default DMA domain of a group doesn't fit a device, it will still sit in the group

Re: [PATCH 1/1] iommu/vt-d: Fix dmar pte read access not set error

On Thu Dec 12 19, Lu Baolu wrote: Hi, On 12/12/19 9:49 AM, Jerry Snitselaar wrote: On Wed Dec 11 19, Lu Baolu wrote: If the default DMA domain of a group doesn't fit a device, it will still sit in the group but use a private identity domain. When map/unmap/iova_to_phys come through iommu API

[PATCH] iommu/vt-d: Allocate reserved region for ISA with correct permission

: d850c2ee5fe2 ("iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions") Signed-off-by: Jerry Snitselaar --- drivers/iommu/intel-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 0c

Re: [PATCH 1/1] iommu/vt-d: Fix dmar pte read access not set error

On Thu Dec 12 19, Jerry Snitselaar wrote: On Fri Dec 13 19, Lu Baolu wrote: Hi, On 12/13/19 8:30 AM, Jerry Snitselaar wrote: On Thu Dec 12 19, Lu Baolu wrote: Hi, On 12/12/19 9:49 AM, Jerry Snitselaar wrote: On Wed Dec 11 19, Lu Baolu wrote: If the default DMA domain of a group doesn't

Re: panic in dmar_remove_one_dev_info

On Mon Dec 16 19, Jerry Snitselaar wrote: HP is seeing a panic on gen9 dl360 and dl560 while testing these other changes we've been eorking on. I just took an initial look, but have to run to a dentist appointment so couldn't dig too deep. It looks like the device sets dev->archdata.io

[RFC PATCH] iommu/vt-d: avoid panic in __dmar_remove_one_dev_info

c: sta...@vger.kernel.org # v5.3+ Cc: iommu@lists.linux-foundation.org Fixes: ae23bfb68f28 ("iommu/vt-d: Detach domain before using a private one") Signed-off-by: Jerry Snitselaar --- drivers/iommu/intel-iommu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iom

Re: [RFC PATCH] iommu/vt-d: avoid panic in __dmar_remove_one_dev_info

On Tue, Dec 17, 2019 at 10:56 AM Jerry Snitselaar wrote: > > In addition to checking for a null pointer, verify that > info does not have the value DEFER_DEVICE_DOMAIN_INFO or > DUMMY_DEVICE_DOMAIN_INFO. If info has one of those values > __dmar_remove_one_dev_info will panic when t

Re: [RFC PATCH] iommu/vt-d: avoid panic in __dmar_remove_one_dev_info

On Tue Dec 17 19, Jerry Snitselaar wrote: On Tue Dec 17 19, Jerry Snitselaar wrote: In addition to checking for a null pointer, verify that info does not have the value DEFER_DEVICE_DOMAIN_INFO or DUMMY_DEVICE_DOMAIN_INFO. If info has one of those values __dmar_remove_one_dev_info will panic

Re: [RFC PATCH] iommu/vt-d: avoid panic in __dmar_remove_one_dev_info

On Tue Dec 17 19, Jerry Snitselaar wrote: In addition to checking for a null pointer, verify that info does not have the value DEFER_DEVICE_DOMAIN_INFO or DUMMY_DEVICE_DOMAIN_INFO. If info has one of those values __dmar_remove_one_dev_info will panic when trying to access a member

Re: [PATCH 1/1] iommu/vt-d: Fix dmar pte read access not set error

device in the group needs dma and gets a private dma domain? Link: https://www.spinics.net/lists/iommu/msg40416.html Cc: Jerry Snitselaar Reported-by: Jerry Snitselaar Fixes: 942067f1b6b97 ("iommu/vt-d: Identify default domains replaced with private") Cc: sta...@vger.kernel.org # v5.3+

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Fri Dec 06 19, Lu Baolu wrote: [snip] Can you please try below change? Let's check whether the afending address has been mapped for device 01.00.2. $ git diff diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index db7bfd4f2d20..d9daf66be849 100644 --- a/drivers/iommu/iommu.c +++

panic in dmar_remove_one_dev_info

HP is seeing a panic on gen9 dl360 and dl560 while testing these other changes we've been eorking on. I just took an initial look, but have to run to a dentist appointment so couldn't dig too deep. It looks like the device sets dev->archdata.iommu to DEFER_DEVICE_DOMAIN_INFO in

[PATCH] iommu: set group default domain before creating direct mappings

oup default domain is set, so the direct mappings get associated with that domain. Cc: Joerg Roedel Cc: Lu Baolu Cc: iommu@lists.linux-foundation.org Cc: sta...@vger.kernel.org Fixes: 7423e01741dd ("iommu: Add API to request DMA domain for device") Signed-off-by: Jerry Snitselaar ---

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Sun Dec 08 19, Lu Baolu wrote: Hi, On 12/7/19 10:41 AM, Jerry Snitselaar wrote: On Fri Dec 06 19, Jerry Snitselaar wrote: On Sat Dec 07 19, Lu Baolu wrote: Hi Jerry, On 12/6/19 3:24 PM, Jerry Snitselaar wrote: On Fri Dec 06 19, Lu Baolu wrote: [snip] Can you please try below change

Re: [PATCH 1/1] iommu/vt-d: Fix dmar pte read access not set error

will be impacted. Since identity domain has been mapped with the whole available memory space and RMRRs, we don't need to worry about the impact on it. Link: https://www.spinics.net/lists/iommu/msg40416.html Cc: Jerry Snitselaar Reported-by: Jerry Snitselaar Fixes: 942067f1b6b97 ("iommu/vt-d: Ide

Re: [PATCH] iommu/amd: Pass gfp flags to iommu_map_page() in amd_iommu_map()

tion.org https://lists.linuxfoundation.org/mailman/listinfo/iommu Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH -next] iommu/amd: fix a warning in increase_address_space

On Wed Oct 16 19, Jerry Snitselaar wrote: On Wed Oct 16 19, Qian Cai wrote: BTW, Joerg, this line from the commit "iommu/amd: Remove domain->updated" looks suspicious. Not sure what the purpose of it. *updated = increase_address_space(domain, gfp) || *updated; Looking at it

Re: [PATCH -next] iommu/amd: fix a warning in increase_address_space

On Wed Oct 16 19, Qian Cai wrote: After the commit 754265bcab78 ("iommu/amd: Fix race in increase_address_space()"), it could still possible trigger a race condition under some heavy memory pressure below. The race to trigger a warning is, CPU0: CPU1: in alloc_pte():

Re: [PATCH] iommu/amd: Check PM_LEVEL_SIZE() condition in locked section

On Fri Oct 18 19, Joerg Roedel wrote: On Thu, Oct 17, 2019 at 07:36:51AM -0400, Qian Cai wrote: > On Oct 16, 2019, at 6:59 PM, Jerry Snitselaar wrote: > > I guess the mode level 6 check is really for other potential callers > increase_address_space, none exist a

Re: [PATCH v3] iommu: fix KASAN use-after-free in iommu_insert_resv_region

v_region() implementation") Signed-off-by: Eric Auger Reported-by: Qian Cai Cc: Stable #v5.3+ Minor nit, but should the comment above list_for_each_entry_safe get updated as well? Other than that, lgtm. Reviewed-by: Jerry Snitselaar --- v2 -> v3: - directly use new->type v1 -> v2: - re

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Mon Dec 02 19, Jerry Snitselaar wrote: On Mon Dec 02 19, Lu Baolu wrote: Hi, On 12/2/19 2:34 PM, Jerry Snitselaar wrote: We are seeing DMAR PTE read access not set errors when booting a kernel with default passthrough, both with a test kernel and with a 5.4.0 kernel. Previously we would

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Mon Dec 02 19, Lu Baolu wrote: Hi, On 12/2/19 2:34 PM, Jerry Snitselaar wrote: We are seeing DMAR PTE read access not set errors when booting a kernel with default passthrough, both with a test kernel and with a 5.4.0 kernel. Previously we would see a number of identity mappings being set

dmar pte read access not set error messages on hp dl388 gen8 systems

We are seeing DMAR PTE read access not set errors when booting a kernel with default passthrough, both with a test kernel and with a 5.4.0 kernel. Previously we would see a number of identity mappings being set related to the rmrrs, and now they aren't seen and we get the dmar pte errors as

Re: [PATCH v2 6/6] iommu/amd: Switch to use acpi_dev_hid_uid_match()

On Tue Sep 24 19, Andy Shevchenko wrote: Since we have a generic helper, drop custom implementation in the driver. Signed-off-by: Andy Shevchenko --- Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https

Re: [PATCH 0/2] iommu/vt-d: Select PCI_PRI for INTEL_IOMMU_SVM

changed, 31 insertions(+), 36 deletions(-) -- 2.23.0.581.g78d2f28ef7-goog ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu Reviewed-by: Jerry Snitselaar

Re: [PATCH v3 6/6] iommu/amd: Switch to use acpi_dev_hid_uid_match()

g list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/vt-d: Don't reject nvme host due to scope mismatch

On Fri Dec 20 19, jimyan wrote: On a system with an Intel PCIe port configured as a nvme host device, iommu initialization fails with DMAR: Device scope type does not match for :80:00.0 This is because the DMAR table reports this device as having scope 2 (ACPI_DMAR_SCOPE_TYPE_BRIDGE):

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Mon Dec 09 19, Jerry Snitselaar wrote: On Mon Dec 09 19, Jerry Snitselaar wrote: [snip] A call to iommu_map is failing. [ 36.686881] pci :01:00.2: iommu_group_add_device: calling iommu_group_create_direct_mappings [ 36.689843] pci :01:00.2: iommu_group_create_direct_mappings

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Tue Dec 10 19, Lu Baolu wrote: Hi, On 12/10/19 8:52 AM, Jerry Snitselaar wrote: On Sun Dec 08 19, Lu Baolu wrote: Hi, On 12/7/19 10:41 AM, Jerry Snitselaar wrote: On Fri Dec 06 19, Jerry Snitselaar wrote: On Sat Dec 07 19, Lu Baolu wrote: Hi Jerry, On 12/6/19 3:24 PM, Jerry Snitselaar

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Mon Dec 09 19, Jerry Snitselaar wrote: [snip] A call to iommu_map is failing. [ 36.686881] pci :01:00.2: iommu_group_add_device: calling iommu_group_create_direct_mappings [ 36.689843] pci :01:00.2: iommu_group_create_direct_mappings: iterating through mappings [ 36.692757

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Mon Dec 09 19, Jerry Snitselaar wrote: On Mon Dec 09 19, Jerry Snitselaar wrote: On Mon Dec 09 19, Jerry Snitselaar wrote: [snip] A call to iommu_map is failing. [ 36.686881] pci :01:00.2: iommu_group_add_device: calling iommu_group_create_direct_mappings [ 36.689843] pci :01

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

On Tue Dec 10 19, Lu Baolu wrote: Hi, On 12/10/19 2:16 PM, Jerry Snitselaar wrote: On Mon Dec 09 19, Jerry Snitselaar wrote: On Mon Dec 09 19, Jerry Snitselaar wrote: On Mon Dec 09 19, Jerry Snitselaar wrote: [snip] A call to iommu_map is failing. [   36.686881] pci :01:00.2

warning from domain_get_iommu

I'm working on getting a system to reproduce this, and verify it also occurs with 5.5, but I have a report of a case where the kdump kernel gives warnings like the following on a hp dl360 gen9: [2.830589] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [2.832615] ehci-pci:

Re: Seeing some another issue with mixed domains in the same iommu_group

On Thu Feb 06 20, Jerry Snitselaar wrote: Hi Baolu, I'm seeing another issue with the devices in the HP ilo when the system is booted with intel_iommu=on and iommu=pt (iommu=nopt does not run into problems). first system: 01:00.0 System peripheral: Hewlett-Packard Company Integrated Lights

Re: warning from domain_get_iommu

On Tue Feb 04 20, Jerry Snitselaar wrote: I'm working on getting a system to reproduce this, and verify it also occurs with 5.5, but I have a report of a case where the kdump kernel gives warnings like the following on a hp dl360 gen9: [2.830589] ehci_hcd: USB 2.0 'Enhanced' Host Controller

Seeing some another issue with mixed domains in the same iommu_group

Hi Baolu, I'm seeing another issue with the devices in the HP ilo when the system is booted with intel_iommu=on and iommu=pt (iommu=nopt does not run into problems). first system: 01:00.0 System peripheral: Hewlett-Packard Company Integrated Lights-Out Standard Slave Instrumentation & System

Re: Seeing some another issue with mixed domains in the same iommu_group

On Thu Feb 06 20, Jerry Snitselaar wrote: ... The above cases seem to be avoided by: 9235cb13d7d1 | 2020-01-24 | iommu/vt-d: Allow devices with RMRRs to use identity domain (Lu Baolu) which results in the watchdog device no longer taking a dma domain and switching the group default

Re: warning from domain_get_iommu

On Thu Feb 06 20, Jerry Snitselaar wrote: On Tue Feb 04 20, Jerry Snitselaar wrote: I'm working on getting a system to reproduce this, and verify it also occurs with 5.5, but I have a report of a case where the kdump kernel gives warnings like the following on a hp dl360 gen9: [2.830589

Re: Seeing some another issue with mixed domains in the same iommu_group

On Thu Feb 06 20, Jerry Snitselaar wrote: On Thu Feb 06 20, Jerry Snitselaar wrote: Hi Baolu, I'm seeing another issue with the devices in the HP ilo when the system is booted with intel_iommu=on and iommu=pt (iommu=nopt does not run into problems). first system: 01:00.0 System peripheral

Re: warning from domain_get_iommu

On Sat Feb 08 20, Lu Baolu wrote: Hi Jerry, On 2020/2/7 17:34, Jerry Snitselaar wrote: On Thu Feb 06 20, Jerry Snitselaar wrote: On Tue Feb 04 20, Jerry Snitselaar wrote: I'm working on getting a system to reproduce this, and verify it also occurs with 5.5, but I have a report of a case

Re: arm-smmu.1.auto: Unhandled context fault starting with 5.4-rc1

On Mon Feb 17 20, Robin Murphy wrote: On 16/02/2020 10:11 pm, Jerry Snitselaar wrote: On Fri Feb 14 20, Robin Murphy wrote: Hi Jerry, On 2020-02-14 8:13 pm, Jerry Snitselaar wrote: Hi Will, On a gigabyte system with Cavium CN8xx, when doing a fio test against an nvme drive we are seeing

Re: [PATCH 5/5] iommu/vt-d: Simplify check in identity_mapping()

On Mon Feb 17 20, Joerg Roedel wrote: From: Joerg Roedel The function only has one call-site and there it is never called with dummy or deferred devices. Simplify the check in the function to account for that. Signed-off-by: Joerg Roedel Reviewed-by: Jerry Snitselaar

Re: [PATCH 1/5] iommu/vt-d: Add attach_deferred() helper

On Mon Feb 17 20, Joerg Roedel wrote: From: Joerg Roedel Implement a helper function to check whether a device's attach process is deferred. Signed-off-by: Joerg Roedel Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux

Re: [PATCH 3/5] iommu/vt-d: Do deferred attachment in iommu_need_mapping()

] ata_host_start.part.39+0x104/0x1e0 [libata] With the earlier check the kdump boot succeeds and a crashdump is written. Signed-off-by: Joerg Roedel Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https

Re: [PATCH 2/5] iommu/vt-d: Move deferred device attachment into helper function

On Mon Feb 17 20, Joerg Roedel wrote: From: Joerg Roedel Move the code that does the deferred device attachment into a separate helper function. Signed-off-by: Joerg Roedel Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux

Re: [PATCH 4/5] iommu/vt-d: Remove deferred_attach_domain()

On Mon Feb 17 20, Joerg Roedel wrote: From: Joerg Roedel The function is now only a wrapper around find_domain(). Remove the function and call find_domain() directly at the call-sites. Signed-off-by: Joerg Roedel Reviewed-by: Jerry Snitselaar

Re: dmar fault right around domain switch in iommu_need_mapping

On Wed Feb 19 20, Lu Baolu wrote: Hi Jerry, On 2020/2/18 23:45, Jerry Snitselaar wrote: Hi Joerg and Baolu, I'm chasing down one last issue. I'm waiting to hear back from them testing with Joerg's patchset, but I'm guessing this will still pop up. It looks like right around when the domain

Re: question about iommu_need_mapping

On Thu Feb 20 20, Lu Baolu wrote: Hi Jerry, On 2020/2/20 7:55, Jerry Snitselaar wrote: Is it possible for a device to end up with dev->archdata.iommu == NULL on iommu_need_mapping in the following instance: 1. iommu_group has dma domain for default 2. device gets private identity dom

Re: question about iommu_need_mapping

On Thu Feb 20 20, Jerry Snitselaar wrote: On Thu Feb 20 20, Lu Baolu wrote: Hi Jerry, On 2020/2/20 7:55, Jerry Snitselaar wrote: Is it possible for a device to end up with dev->archdata.iommu == NULL on iommu_need_mapping in the following instance: 1. iommu_group has dma domain for defaul

arm-smmu.1.auto: Unhandled context fault starting with 5.4-rc1

Hi Will, On a gigabyte system with Cavium CN8xx, when doing a fio test against an nvme drive we are seeing the following: [ 637.161194] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr=0x8402, iova=0x8010003f6000, fsynr=0x70091, cbfrsynra=0x9000, cb=7 [ 637.174329] arm-smmu

Re: arm-smmu.1.auto: Unhandled context fault starting with 5.4-rc1

On Fri Feb 14 20, Robin Murphy wrote: Hi Jerry, On 2020-02-14 8:13 pm, Jerry Snitselaar wrote: Hi Will, On a gigabyte system with Cavium CN8xx, when doing a fio test against an nvme drive we are seeing the following: [  637.161194] arm-smmu arm-smmu.1.auto: Unhandled context fault: fsr

question about iommu_need_mapping

Is it possible for a device to end up with dev->archdata.iommu == NULL on iommu_need_mapping in the following instance: 1. iommu_group has dma domain for default 2. device gets private identity domain in intel_iommu_add_device 3. iommu_need_mapping gets called with that device. 4.

dmar fault right around domain switch in iommu_need_mapping

Hi Joerg and Baolu, I'm chasing down one last issue. I'm waiting to hear back from them testing with Joerg's patchset, but I'm guessing this will still pop up. It looks like right around when the domain switch occurs in iommu_need_mapping there are some dmar faults (below is from 5.6-rc1 plus

Re: [PATCH 3/5 v2] iommu/vt-d: Do deferred attachment in iommu_need_mapping()

ntel_alloc_coherent+0xac/0x110 dmam_alloc_attrs+0x50/0xa0 ahci_port_start+0xfb/0x1f0 [libahci] ata_host_start.part.39+0x104/0x1e0 [libata] With the earlier check the kdump boot succeeds and a crashdump is written. Signed-off-by: Joerg Roedel

[PATCH] iommu/vt-d: call __dmar_remove_one_dev_info with valid pointer

. Cc: Joerg Roedel Cc: Lu Baolu Cc: David Woodhouse Cc: sta...@vger.kernel.org # 5.3+ Cc: linux-ker...@vger.kernel.org Fixes: ae23bfb68f28 ("iommu/vt-d: Detach domain before using a private one") Signed-off-by: Jerry Snitselaar --- drivers/iommu/intel-iommu.c | 3 ++- 1 file

Re: [PATCH 1/1] iommu/vt-d: Add a quirk flag for scope mismatched devices

for those special devices. Cc: Roland Dreier Cc: Jim Yan Signed-off-by: Lu Baolu --- Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices

On Wed Jan 01 20, Roland Dreier via iommu wrote: We saw more devices with the same mismatch quirk. So maintaining them in a quirk table will make it more readable and maintainable. I guess I disagree about the maintainable part, given that this patch already regresses Broadwell NTB. I'm not

Re: [PATCH 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices

On Tue Jan 07 20, Lu Baolu wrote: Hi Jerry, On 1/7/20 1:05 AM, Jerry Snitselaar wrote: On Wed Jan 01 20, Roland Dreier via iommu wrote: We saw more devices with the same mismatch quirk. So maintaining them in a quirk table will make it more readable and maintainable. I guess I disagree

Re: [PATCH v2] iommu/vt-d: Don't reject nvme host due to scope mismatch

Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 0/3] Replace private domain with per-group default domain

o use DMA domain iommu/vt-d: Apply per-device dma_ops drivers/iommu/intel-iommu.c | 396 +++- 1 file changed, 26 insertions(+), 370 deletions(-) -- 2.17.1 Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@li

amd kdump failure with iommu=nopt

We've seen kdump failures with recent kernels (5.5, 5.6, 5.7-rc1) on amd systems when iommu is enabled in translation mode. In the cases so far there has been mpt3sas involved, but I'm also seeing io page faults for ahci right before mpt3sas has an io page fault: [ 15.156620] ahci

Re: [PATCH] iommu: Implement deferred domain attachment

On Mon May 18 20, Joerg Roedel wrote: On Fri, May 15, 2020 at 08:23:13PM +0100, Robin Murphy wrote: But that's not what this is; this is (supposed to be) the exact same "don't actually perform the attach yet" logic as before, just restricting it to default domains in the one place that it

Re: [PATCH] iommu: Implement deferred domain attachment

On Mon May 18 20, Joerg Roedel wrote: On Fri, May 15, 2020 at 08:23:13PM +0100, Robin Murphy wrote: But that's not what this is; this is (supposed to be) the exact same "don't actually perform the attach yet" logic as before, just restricting it to default domains in the one place that it

Re: amd kdump failure with iommu=nopt

eferred(domain, dev)) + __iommu_attach_device_no_defer(domain, dev); + + return domain; } /* ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mai

kdump boot failing with IVRS checksum failure

Hello Joerg, We are seeing a kdump kernel boot failure in test on an HP DL325 Gen10 and it was tracked down to 387caf0b759a ("iommu/amd: Treat per-device exclusion ranges as r/w unity-mapped regions"). Reproduced on 5.9-rc5 and goes away with revert of the commit. There is a follow on commit

Re: [PATCH v2 00/33] iommu: Move iommu_group setup to IOMMU core code

On Tue Apr 14 20, Joerg Roedel wrote: Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-j...@8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 *

Re: [PATCH v2 00/33] iommu: Move iommu_group setup to IOMMU core code

On Fri May 29 20, Jerry Snitselaar wrote: On Tue Apr 14 20, Joerg Roedel wrote: Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-j...@8bytes.org/ Changes v1->

Re: [PATCH v2 00/33] iommu: Move iommu_group setup to IOMMU core code

On Mon Jun 01 20, Jerry Snitselaar wrote: On Fri May 29 20, Jerry Snitselaar wrote: On Tue Apr 14 20, Joerg Roedel wrote: Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml

Re: [PATCH v2 00/33] iommu: Move iommu_group setup to IOMMU core code

On Tue Jun 02 20, Lu Baolu wrote: Hi Jerry, On 6/1/20 6:42 PM, Jerry Snitselaar wrote: Hi Joerg, With this patchset, I have an epyc system where if I boot with iommu=nopt and force a dump I will see some io page faults for a nic on the system. The vmcore is harvested and the system reboots

Re: [PATCH v2 00/33] iommu: Move iommu_group setup to IOMMU core code

On Tue Jun 02 20, Joerg Roedel wrote: Hi Jerry, On Mon, Jun 01, 2020 at 05:02:36PM -0700, Jerry Snitselaar wrote: Yeah, that will solve the panic. If you still see the kdump faults, can you please try with the attached diff? I was not able to reproduce them in my setup. Regards

[PATCH v2 1/2] iommu/vt-d: Move Kconfig and Makefile bits down into intel directory

Move Intel Kconfig and Makefile bits down into intel directory with the rest of the Intel specific files. Cc: Joerg Roedel Cc: Lu Baolu Signed-off-by: Jerry Snitselaar --- drivers/iommu/Kconfig| 86 +--- drivers/iommu/Makefile | 8 +--- drivers

[PATCH v2 2/2] iommu/amd: Move Kconfig and Makefile bits down into amd directory

Move AMD Kconfig and Makefile bits down into the amd directory with the rest of the AMD specific files. Cc: Joerg Roedel Cc: Suravee Suthikulpanit Signed-off-by: Jerry Snitselaar --- drivers/iommu/Kconfig | 45 +- drivers/iommu/Makefile | 5

  1   2   >