On Sat, Jun 25, 2022 at 12:52:27PM -0700, Fenghua Yu wrote:
> Hi, Jerry and Baolu,
>
> On Fri, Jun 24, 2022 at 07:47:30AM -0700, Jerry Snitselaar wrote:
> > > > > > > Hi Baolu & Dave,
> > > > > fails.
> > > > >
> > &g
On Fri, Jun 24, 2022 at 06:41:02AM -0700, Jerry Snitselaar wrote:
> On Fri, Jun 24, 2022 at 09:43:30AM +0800, Baolu Lu wrote:
> > On 2022/6/24 09:14, Jerry Snitselaar wrote:
> > > On Fri, Jun 24, 2022 at 08:55:08AM +0800, Baolu Lu wrote:
> > > > On 2022/6/24
On Fri, Jun 24, 2022 at 09:43:30AM +0800, Baolu Lu wrote:
> On 2022/6/24 09:14, Jerry Snitselaar wrote:
> > On Fri, Jun 24, 2022 at 08:55:08AM +0800, Baolu Lu wrote:
> > > On 2022/6/24 01:02, Jerry Snitselaar wrote:
> > > > Hi Baolu & Dave,
> > > >
&
On Fri, Jun 24, 2022 at 08:55:08AM +0800, Baolu Lu wrote:
> On 2022/6/24 01:02, Jerry Snitselaar wrote:
> > Hi Baolu & Dave,
> >
> > I noticed last night that on a Sapphire Rapids system if you boot without
> > intel_iommu=on, the idxd driver will crash during prob
Hi Baolu & Dave,
I noticed last night that on a Sapphire Rapids system if you boot without
intel_iommu=on, the idxd driver will crash during probe in
iommu_sva_bind_device().
Should there be a sanity check before calling dev_iommu_ops(), or is the
expectation
that the caller would verify it is s
On Thu, Jun 23, 2022 at 10:29:35AM +0800, Baolu Lu wrote:
> On 2022/6/22 23:05, Jerry Snitselaar wrote:
> > On Wed, Jun 22, 2022 at 7:52 AM Baolu Lu wrote:
> > > On 2022/6/16 02:36, Steve Wahl wrote:
> > > > To support up to 64 sockets with 10 DMAR units each (6
On Wed, Jun 22, 2022 at 7:52 AM Baolu Lu wrote:
>
> On 2022/6/16 02:36, Steve Wahl wrote:
> > To support up to 64 sockets with 10 DMAR units each (640), make the
> > value of DMAR_UNITS_SUPPORTED adjustable by a config variable,
> > CONFIG_DMAR_UNITS_SUPPORTED, and make it's default 1024 when MAXS
mode x2apic disabled"; and the system
> fails to boot properly.
>
> Signed-off-by: Steve Wahl
> Reviewed-by: Kevin Tian
Reviewed-by: Jerry Snitselaar
> ---
>
> Note that we could not find a reason for connecting
> DMAR_UNITS_SUPPORTED to MAX_IO_APICS as was done
On Tue, Jun 14, 2022 at 11:45:35AM -0500, Steve Wahl wrote:
> On Tue, Jun 14, 2022 at 10:21:29AM +0800, Baolu Lu wrote:
> > On 2022/6/14 09:54, Jerry Snitselaar wrote:
> > > On Mon, Jun 13, 2022 at 6:51 PM Baolu Lu wrote:
> > > >
> > > > On 2022/6/14 0
On Mon, Jun 13, 2022 at 6:51 PM Baolu Lu wrote:
>
> On 2022/6/14 09:44, Jerry Snitselaar wrote:
> > On Mon, Jun 13, 2022 at 6:36 PM Baolu Lu wrote:
> >> On 2022/6/14 04:57, Jerry Snitselaar wrote:
> >>> On Thu, May 12, 2022 at 10:13:09AM -0500, Steve Wahl
On Mon, Jun 13, 2022 at 6:36 PM Baolu Lu wrote:
>
> On 2022/6/14 04:57, Jerry Snitselaar wrote:
> > On Thu, May 12, 2022 at 10:13:09AM -0500, Steve Wahl wrote:
> >> To support up to 64 sockets with 10 DMAR units each (640), make the
> >> value of DMAR_UNITS_SU
On Thu, May 12, 2022 at 10:13:09AM -0500, Steve Wahl wrote:
> To support up to 64 sockets with 10 DMAR units each (640), make the
> value of DMAR_UNITS_SUPPORTED adjustable by a config variable,
> CONFIG_DMAR_UNITS_SUPPORTED, and make it's default 1024 when MAXSMP is
> set.
>
> If the available ha
On Thu, May 12, 2022 at 10:13:09AM -0500, Steve Wahl wrote:
> To support up to 64 sockets with 10 DMAR units each (640), make the
> value of DMAR_UNITS_SUPPORTED adjustable by a config variable,
> CONFIG_DMAR_UNITS_SUPPORTED, and make it's default 1024 when MAXSMP is
> set.
>
> If the available ha
On Fri, 2021-11-12 at 10:59 +0800, Lu Baolu wrote:
> Hi Alex,
>
> On 11/11/21 8:32 AM, Alex Williamson wrote:
> > When supporting only the .map and .unmap callbacks of iommu_ops,
> > the IOMMU driver can make assumptions about the size and alignment
> > used for mappings based on the driver provid
,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
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:
> >
&
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
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 t
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 file
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 t
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,
>>>>
>>>> On
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
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
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'
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
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
tha
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
> wa
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
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
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
/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
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
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
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
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
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
--- a
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&#
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
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
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 to
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
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
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
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->
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
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 actual
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 actual
ach_deferred(domain, dev))
+ __iommu_attach_device_no_defer(domain, dev);
+
+ return domain;
}
/*
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.or
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 :63:00.0:
ierarchy to 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 lis
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
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 domain
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_remove_one
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 ar
intel_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 Roed
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 ear
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
]
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
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
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
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.
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 the
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
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 arm-smmu
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
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.8
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
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 perip
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 L
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 S
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'
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: EHCI
.
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
yan
Reviewed-by: Jerry Snitselaar
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
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 ev
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
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):
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
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 of the
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
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
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->arch
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 intel_iommu_add_dev
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 iomm
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
: 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
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&#
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
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 iomm
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
ut a later 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.or
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
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
---
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
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
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
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
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
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
1 - 100 of 137 matches
Mail list logo
