Re: [PATCH] iommu/amd: Add sanity check for interrupt remapping table length macros

2020-12-10 Thread Jerry Snitselaar
,7 +3191,7 @@ static void set_dte_irq_entry(u16 devid, struct > irq_remap_table *table) > dte &= ~DTE_IRQ_PHYS_ADDR_MASK; > dte |= iommu_virt_to_phys(table->table); > dte |= DTE_IRQ_REMAP_INTCTL; > - dte |= DTE_IRQ_TABLE_LEN; > + dte |= DTE_INTTABLEN; > dte |= DTE_IRQ_REMAP_ENABLE; > > amd_iommu_dev_table[devid].data[2] = dte; Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [GIT PULL] IOMMU fix for 5.10 (-final)

2020-12-09 Thread Jerry Snitselaar
On Wed, Dec 9, 2020 at 12:18 PM Linus Torvalds wrote: > > On Wed, Dec 9, 2020 at 11:12 AM Jerry Snitselaar wrote: > > > > Since the field in the device table entry format expects it to be n > > where there are 2^n entries in the table I guess it should be: > > &

Re: [GIT PULL] IOMMU fix for 5.10 (-final)

2020-12-09 Thread Jerry Snitselaar
On Wed, Dec 9, 2020 at 12:12 PM Jerry Snitselaar wrote: > > > Will Deacon @ 2020-12-09 11:50 MST: > > > On Wed, Dec 09, 2020 at 10:07:46AM -0800, Linus Torvalds wrote: > >> On Wed, Dec 9, 2020 at 6:12 AM Will Deacon wrote: > >> > > >> > Plea

Re: [GIT PULL] IOMMU fix for 5.10 (-final)

2020-12-09 Thread Jerry Snitselaar
Will Deacon @ 2020-12-09 11:50 MST: > On Wed, Dec 09, 2020 at 10:07:46AM -0800, Linus Torvalds wrote: >> On Wed, Dec 9, 2020 at 6:12 AM Will Deacon wrote: >> > >> > Please pull this one-liner AMD IOMMU fix for 5.10. It's actually a fix >> > for a fix, where the size of the interrupt remapping

Re: [PATCH] iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs

2020-12-07 Thread Jerry Snitselaar
e device table mapping entry (DTE). > > Fixes: 73db2fc595f3 ("iommu/amd: Increase interrupt remapping table limit to > 512 entries") > Reported-by: Jerry Snitselaar > Signed-off-by: Suravee Suthikulpanit > --- > drivers/iommu/amd/amd_iommu_types.h | 2 +- > 1 fi

Re: [PATCH] iommu/amd: Increase interrupt remapping table limit to 512 entries

2020-12-01 Thread Jerry Snitselaar
Suravee Suthikulpanit @ 2020-10-14 19:50 MST: > Certain device drivers allocate IO queues on a per-cpu basis. > On AMD EPYC platform, which can support up-to 256 cpu threads, > this can exceed the current MAX_IRQ_PER_TABLE limit of 256, > and result in the error message: > > AMD-Vi: Failed

Re: Question about domain_init (v5.3-v5.7)

2020-11-30 Thread Jerry Snitselaar
Jerry Snitselaar @ 2020-11-30 10:50 MST: > Lu Baolu @ 2020-11-26 19:12 MST: > >> Hi Jerry, >> >> On 11/27/20 5:35 AM, Jerry Snitselaar wrote: >>> Lu Baolu @ 2020-11-26 04:01 MST: >>> >>>> Hi Jerry, >>>> >>>>

Re: Question about domain_init (v5.3-v5.7)

2020-11-30 Thread Jerry Snitselaar
Lu Baolu @ 2020-11-26 19:12 MST: > Hi Jerry, > > On 11/27/20 5:35 AM, Jerry Snitselaar wrote: >> Lu Baolu @ 2020-11-26 04:01 MST: >> >>> Hi Jerry, >>> >>> On 2020/11/26 4:27, Jerry Snitselaar wrote: >>>> Is there a reason we check the

Re: Question about domain_init (v5.3-v5.7)

2020-11-26 Thread Jerry Snitselaar
Lu Baolu @ 2020-11-26 19:12 MST: > Hi Jerry, > > On 11/27/20 5:35 AM, Jerry Snitselaar wrote: >> Lu Baolu @ 2020-11-26 04:01 MST: >> >>> Hi Jerry, >>> >>> On 2020/11/26 4:27, Jerry Snitselaar wrote: >>>> Is there a reason we check the

Re: Question about domain_init (v5.3-v5.7)

2020-11-26 Thread Jerry Snitselaar
Lu Baolu @ 2020-11-26 04:01 MST: > Hi Jerry, > > On 2020/11/26 4:27, Jerry Snitselaar wrote: >> Is there a reason we check the requested guest address width against >> the >> iommu's mgaw, instead of the agaw that we already know for the iommu? >> I've run in

Question about domain_init (v5.3-v5.7)

2020-11-25 Thread Jerry Snitselaar
Is there a reason we check the requested guest address width against the iommu's mgaw, instead of the agaw that we already know for the iommu? I've run into a case with a new system where the mgaw reported is 57, but if they set PAE to 46 instead of 52 in the bios, then sagaw reports the highest

kdump boot failing with IVRS checksum failure

2020-09-21 Thread Jerry Snitselaar
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 0/2] iommu: Move AMD and Intel Kconfig + Makefile bits into their directories

2020-07-27 Thread Jerry Snitselaar
Jerry Snitselaar @ 2020-06-30 13:06 MST: > This patchset imeplements the suggestion from Linus to move the > Kconfig and Makefile bits for AMD and Intel into their respective > directories. > > v2: Rebase against v5.8-rc3. Dropped ---help--- changes from Kconfig as that &g

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

2020-06-30 Thread Jerry Snitselaar
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

[PATCH v2 0/2] iommu: Move AMD and Intel Kconfig + Makefile bits into their directories

2020-06-30 Thread Jerry Snitselaar
This patchset imeplements the suggestion from Linus to move the Kconfig and Makefile bits for AMD and Intel into their respective directories. v2: Rebase against v5.8-rc3. Dropped ---help--- changes from Kconfig as that was dealt with in systemwide cleanup. Jerry Snitselaar (2): iommu

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

2020-06-30 Thread Jerry Snitselaar
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

Re: [PATCH 00/13] iommu: Remove usage of dev->archdata.iommu

2020-06-25 Thread Jerry Snitselaar
/s5p-mfc/s5p_mfc_iommu.h| 4 +++- 17 files changed, 64 insertions(+), 71 deletions(-) -- 2.27.0 Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/1] iommu/vt-d: Fix misuse of iommu_domain_identity_map()

2020-06-18 Thread Jerry Snitselaar
d-by: Alex Williamson Signed-off-by: Lu Baolu Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2020-06-12 Thread Jerry Snitselaar
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

[PATCH 0/2] iommu: Move AMD and Intel Kconfig + Makefile bits into their directories

2020-06-12 Thread Jerry Snitselaar
This patchset imeplements the suggestion from Linus to move the Kconfig and Makefile bits for AMD and Intel into their respective directories. It also cleans up a couple Kconfig entries to use the newer help attribute instead of ---help--- (complaint from checkpatch). Jerry Snitselaar (2

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

2020-06-12 Thread Jerry Snitselaar
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] iommu: add include/uapi/linux/iommu.h to MAINTAINERS file

2020-06-05 Thread Jerry Snitselaar
When include/uapi/linux/iommu.h was created it was never added to the file list in MAINTAINERS. Cc: Joerg Roedel Signed-off-by: Jerry Snitselaar --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index e1897ed32930..061648b6e393 100644

[PATCH] iommu: Don't attach deferred device in iommu_group_do_dma_attach

2020-06-04 Thread Jerry Snitselaar
Attaching a deferred device should be delayed until dma api is called. Cc: iommu@lists.linux-foundation.org Suggested-by: Joerg Roedel Signed-off-by: Jerry Snitselaar --- If you already have thrown a patch together, then ignore this. Also feel free to swap out the signed-off-by with your's

Re: [PATCH 0/2] iommu: Move Intel and AMD drivers into their own subdirectory

2020-06-03 Thread Jerry Snitselaar
On Thu Jun 04 20, Lu Baolu wrote: Hi Joerg, On 6/2/20 5:26 PM, Joerg Roedel wrote: Hi, two small patches to move the Intel and AMD IOMMU drivers into their own subdirectory under drivers/iommu/ to make the file structure a bit less cluttered. Does the MAINTAINERS file need to update? Best

Re: [PATCH 0/2] iommu: Move Intel and AMD drivers into their own subdirectory

2020-06-03 Thread Jerry Snitselaar
el-pasid.c => intel/pasid.c} (100%) rename drivers/iommu/{intel-svm.c => intel/svm.c} (100%) rename drivers/iommu/{intel-trace.c => intel/trace.c} (100%) -- 2.17.1 Reviewed-by: Jerry Snitselaar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

2020-06-02 Thread Jerry Snitselaar
On Tue Jun 02 20, Jerry Snitselaar wrote: 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

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

2020-06-02 Thread Jerry Snitselaar
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

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

2020-06-01 Thread Jerry Snitselaar
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

2020-06-01 Thread Jerry Snitselaar
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

2020-06-01 Thread Jerry Snitselaar
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

2020-05-29 Thread Jerry Snitselaar
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] iommu: Implement deferred domain attachment

2020-05-19 Thread Jerry Snitselaar
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

2020-05-18 Thread Jerry Snitselaar
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

2020-05-14 Thread Jerry Snitselaar
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

amd kdump failure with iommu=nopt

2020-05-13 Thread Jerry Snitselaar
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 v4 0/3] Replace private domain with per-group default domain

2020-05-12 Thread Jerry Snitselaar
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

Re: question about iommu_need_mapping

2020-02-20 Thread Jerry Snitselaar
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

Re: question about iommu_need_mapping

2020-02-20 Thread Jerry Snitselaar
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

question about iommu_need_mapping

2020-02-19 Thread Jerry Snitselaar
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.

Re: dmar fault right around domain switch in iommu_need_mapping

2020-02-18 Thread Jerry Snitselaar
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: [PATCH 3/5 v2] iommu/vt-d: Do deferred attachment in iommu_need_mapping()

2020-02-18 Thread Jerry Snitselaar
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

dmar fault right around domain switch in iommu_need_mapping

2020-02-18 Thread Jerry Snitselaar
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 5/5] iommu/vt-d: Simplify check in identity_mapping()

2020-02-17 Thread Jerry Snitselaar
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 3/5] iommu/vt-d: Do deferred attachment in iommu_need_mapping()

2020-02-17 Thread Jerry Snitselaar
] 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

2020-02-17 Thread Jerry Snitselaar
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()

2020-02-17 Thread Jerry Snitselaar
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: [PATCH 1/5] iommu/vt-d: Add attach_deferred() helper

2020-02-17 Thread Jerry Snitselaar
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: arm-smmu.1.auto: Unhandled context fault starting with 5.4-rc1

2020-02-17 Thread Jerry Snitselaar
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: arm-smmu.1.auto: Unhandled context fault starting with 5.4-rc1

2020-02-16 Thread Jerry Snitselaar
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

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

2020-02-14 Thread Jerry Snitselaar
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: warning from domain_get_iommu

2020-02-08 Thread Jerry Snitselaar
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: warning from domain_get_iommu

2020-02-07 Thread Jerry Snitselaar
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

2020-02-06 Thread Jerry Snitselaar
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: Seeing some another issue with mixed domains in the same iommu_group

2020-02-06 Thread Jerry Snitselaar
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: Seeing some another issue with mixed domains in the same iommu_group

2020-02-06 Thread Jerry Snitselaar
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

Seeing some another issue with mixed domains in the same iommu_group

2020-02-06 Thread Jerry Snitselaar
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: warning from domain_get_iommu

2020-02-06 Thread Jerry Snitselaar
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

warning from domain_get_iommu

2020-02-04 Thread Jerry Snitselaar
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:

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

2020-01-21 Thread Jerry Snitselaar
. 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 v2] iommu/vt-d: Don't reject nvme host due to scope mismatch

2020-01-06 Thread Jerry Snitselaar
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

2020-01-06 Thread Jerry Snitselaar
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 22/22] iommu/vt-d: Add a quirk flag for scope mismatched devices

2020-01-06 Thread Jerry Snitselaar
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 1/1] iommu/vt-d: Add a quirk flag for scope mismatched devices

2019-12-24 Thread Jerry Snitselaar
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] iommu/vt-d: Don't reject nvme host due to scope mismatch

2019-12-20 Thread Jerry Snitselaar
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: [RFC PATCH] iommu/vt-d: avoid panic in __dmar_remove_one_dev_info

2019-12-17 Thread Jerry Snitselaar
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

2019-12-17 Thread Jerry Snitselaar
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: [RFC PATCH] iommu/vt-d: avoid panic in __dmar_remove_one_dev_info

2019-12-17 Thread Jerry Snitselaar
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

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

2019-12-17 Thread Jerry Snitselaar
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: panic in dmar_remove_one_dev_info

2019-12-16 Thread Jerry Snitselaar
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

panic in dmar_remove_one_dev_info

2019-12-16 Thread Jerry Snitselaar
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

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

2019-12-12 Thread Jerry Snitselaar
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

2019-12-12 Thread Jerry Snitselaar
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

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

2019-12-12 Thread Jerry Snitselaar
: 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

2019-12-12 Thread Jerry Snitselaar
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: [PATCH 1/1] iommu/vt-d: Fix dmar pte read access not set error

2019-12-12 Thread Jerry Snitselaar
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

2019-12-12 Thread Jerry Snitselaar
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 1/1] iommu/vt-d: Fix dmar pte read access not set error

2019-12-11 Thread Jerry Snitselaar
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 1/1] iommu/vt-d: Fix dmar pte read access not set error

2019-12-11 Thread Jerry Snitselaar
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

2019-12-10 Thread Jerry Snitselaar
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

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

2019-12-10 Thread Jerry Snitselaar
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

2019-12-09 Thread Jerry Snitselaar
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

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

2019-12-09 Thread Jerry Snitselaar
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

2019-12-09 Thread Jerry Snitselaar
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

2019-12-09 Thread Jerry Snitselaar
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

2019-12-09 Thread Jerry Snitselaar
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

2019-12-09 Thread Jerry Snitselaar
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: dmar pte read access not set error messages on hp dl388 gen8 systems

2019-12-06 Thread Jerry Snitselaar
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

2019-12-06 Thread Jerry Snitselaar
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

2019-12-05 Thread Jerry Snitselaar
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 +++

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

2019-12-04 Thread Jerry Snitselaar
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

2019-12-04 Thread Jerry Snitselaar
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

2019-12-03 Thread Jerry Snitselaar
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

2019-12-02 Thread Jerry Snitselaar
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

2019-12-01 Thread Jerry Snitselaar
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

2019-12-01 Thread Jerry Snitselaar
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 v3] iommu: fix KASAN use-after-free in iommu_insert_resv_region

2019-11-26 Thread Jerry Snitselaar
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: [PATCH] iommu/amd: Check PM_LEVEL_SIZE() condition in locked section

2019-10-18 Thread Jerry Snitselaar
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] iommu/amd: Pass gfp flags to iommu_map_page() in amd_iommu_map()

2019-10-18 Thread Jerry Snitselaar
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

2019-10-16 Thread Jerry Snitselaar
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

2019-10-16 Thread Jerry Snitselaar
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():

  1   2   >