Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
Hi Tvrtko,
On 9/15/20 4:31 PM, Tvrtko Ursulin wrote:
With the previous version of the series I hit a problem on Ivybridge
where apparently the dma engine width is not respected. At least that
is my layman interpretation of the errors. From the older thread:
<3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not
sufficient for the mapped address (008000)
Relevant iommu boot related messages are:
<6>[ 0.184234] DMAR: Host address width 36
<6>[ 0.184245] DMAR: DRHD base: 0x00fed9 flags: 0x0
<6>[ 0.184288] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap
c020e60262 ecap f0101a
<6>[ 0.184308] DMAR: DRHD base: 0x00fed91000 flags: 0x1
<6>[ 0.184337] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap
c9008020660262 ecap f0105a
<6>[ 0.184357] DMAR: RMRR base: 0x00d8d28000 end:
0x00d8d46fff
<6>[ 0.184377] DMAR: RMRR base: 0x00db00 end:
0x00df1f
<6>[ 0.184398] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000
IOMMU 1
<6>[ 0.184414] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
<6>[ 0.184428] DMAR-IR: Queued invalidation will be enabled to
support x2apic and Intr-remapping.
<6>[ 0.185173] DMAR-IR: Enabled IRQ remapping in x2apic mode
<6>[ 0.878934] DMAR: No ATSR found
<6>[ 0.878966] DMAR: dmar0: Using Queued invalidation
<6>[ 0.879007] DMAR: dmar1: Using Queued invalidation
<6>[ 0.915032] DMAR: Intel(R) Virtualization Technology for
Directed I/O
<6>[ 0.915060] PCI-DMA: Using software bounce buffering for IO
(SWIOTLB)
<6>[ 0.915084] software IO TLB: mapped [mem 0xc80d4000-0xcc0d4000]
(64MB)
(Full boot log at
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/boot0.txt,
failures at
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/igt@i915_selftest@l...@blt.html.)
Does this look familiar or at least plausible to you? Is this
something your new series has fixed?
This happens during attaching a domain to device. It has nothing to do
with this patch series. I will look into this issue, but not in this
email thread context.
I am not sure what step is attaching domain to device, but these type
messages:
<3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not
>> sufficient for the mapped address (008000)
They definitely appear to happen at runtime, as i915 is getting
exercised by userspace.
Can you please check whether below change helps here?
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index c8323a9f8bde..0484c539debc 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -724,6 +724,7 @@ static int domain_update_device_node(struct
dmar_domain *domain)
/* Some capabilities may be different across iommus */
static void domain_update_iommu_cap(struct dmar_domain *domain)
{
+ domain->geometry.aperture_end = __DOMAIN_MAX_ADDR(dmar_domain->gaw);
domain_update_iommu_coherency(domain);
domain->iommu_snooping = domain_update_iommu_snooping(NULL);
domain->iommu_superpage = domain_update_iommu_superpage(domain,
NULL);
Best regards,
baolu
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 9/22/20 7:05 PM, Robin Murphy wrote: With the previous version of the series I hit a problem on Ivybridge where apparently the dma engine width is not respected. At least that is my layman interpretation of the errors. From the older thread: <3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not sufficient for the mapped address (008000) Relevant iommu boot related messages are: <6>[ 0.184234] DMAR: Host address width 36 <6>[ 0.184245] DMAR: DRHD base: 0x00fed9 flags: 0x0 <6>[ 0.184288] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap c020e60262 ecap f0101a <6>[ 0.184308] DMAR: DRHD base: 0x00fed91000 flags: 0x1 <6>[ 0.184337] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a <6>[ 0.184357] DMAR: RMRR base: 0x00d8d28000 end: 0x00d8d46fff <6>[ 0.184377] DMAR: RMRR base: 0x00db00 end: 0x00df1f <6>[ 0.184398] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 <6>[ 0.184414] DMAR-IR: HPET id 0 under DRHD base 0xfed91000 <6>[ 0.184428] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. <6>[ 0.185173] DMAR-IR: Enabled IRQ remapping in x2apic mode <6>[ 0.878934] DMAR: No ATSR found <6>[ 0.878966] DMAR: dmar0: Using Queued invalidation <6>[ 0.879007] DMAR: dmar1: Using Queued invalidation <6>[ 0.915032] DMAR: Intel(R) Virtualization Technology for Directed I/O <6>[ 0.915060] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) <6>[ 0.915084] software IO TLB: mapped [mem 0xc80d4000-0xcc0d4000] (64MB) (Full boot log at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/boot0.txt, failures at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/igt@i915_selftest@l...@blt.html.) Does this look familiar or at least plausible to you? Is this something your new series has fixed? This happens during attaching a domain to device. It has nothing to do with this patch series. I will look into this issue, but not in this email thread context. I am not sure what step is attaching domain to device, but these type messages: <3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not >> sufficient for the mapped address (008000) They definitely appear to happen at runtime, as i915 is getting exercised by userspace. AFAICS this certainly might be related to this series - iommu-dma will Oh! I looked at the wrong function. prepare_domain_attach_device() prints a similar message which made me believe that it was not caused by the this patches series. constrain IOVA allocation based on the domain geometry that the driver reports, which in this case is set only once when first allocating the domain. Thus it looks like both the dmar_domain->gaw adjustment in prepare_domain_attach_device() and the domain_use_first_level() business in intel_alloc_iova() effectively get lost in this conversion, since the domain geometry never gets updated to reflect those additional constraints. Sounds reasonable. I will look into the code and work out a fix. > Robin. Best regards, baolu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 2020-09-22 3:51 a.m., Robin Murphy wrote:
> On 2020-09-18 21:47, Logan Gunthorpe wrote:
>> Hi Lu,
>>
>> On 2020-09-11 9:21 p.m., Lu Baolu wrote:
>>> Tom Murphy has almost done all the work. His latest patch series was
>>> posted here.
>>>
>>> https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/
>>>
>>> Thanks a lot!
>>>
>>> This series is a follow-up with below changes:
>>>
>>> 1. Add a quirk for the i915 driver issue described in Tom's cover
>>> letter.
>>> 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use
>>> bounce buffers" to make the bounce buffer work for untrusted devices.
>>> 3. Several cleanups in iommu/vt-d driver after the conversion.
>>>
>>
>> I'm trying to test this on an old Sandy Bridge, but found that I get
>> spammed with warnings on boot. I've put a sample of a few of them below.
>> They all seem to be related to ioat.
>>
>> I had the same issue with Tom's v2 but never saw this on his v1.
>
> I think this might have more to do with ioat being totally broken -
> AFAICS it appears to allocate descriptors with a size of 2MB, but free
> them with a size of 512KB. Try throwing CONFIG_DMA_API_DEBUG at it to
> confirm.
Ah, yes, nice catch. Looks like it was broken recently by the following
commit, but nobody noticed and the dma-iommu patch set added a warning
which caught it.
a02254f8a676 ("dmaengine: ioat: Decreasing allocation chunk size 2M->512K")
Reverting that fixes the issue. I'll try to send patch or two for this.
Logan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 2020-09-21 6:24 p.m., Lu Baolu wrote: I'm trying to test this on an old Sandy Bridge, but found that I get spammed with warnings on boot. I've put a sample of a few of them below. They all seem to be related to ioat. I had the same issue with Tom's v2 but never saw this on his v1. >>> >>> Have you verified whether this could be reproduced with the lasted >>> upstream kernel (without this patch series)? >> >> Yes. > > I am sorry. Just want to make sure I understand you correctly. :-) When > you say "yes", do you mean you could reproduce this with pure upstream > kernel (5.9-rc6)? I mean I've verified the bug does *not* exist without this patch set. > >> Also, it's hitting a warning in the dma-iommu code which would not >> be hit without this patch set. > > Without this series, DMA APIs don't go through dma-iommu. Do you mind > posting the warning message? It was on my original email but here it is again: [ 44.057877] [ cut here ] [ 44.063167] WARNING: CPU: 4 PID: 84 at drivers/iommu/dma-iommu.c:496 __iommu_dma_unmap+0x115/0x130 [ 44.073351] Modules linked in: [ 44.076882] CPU: 4 PID: 84 Comm: kworker/4:1 Tainted: GW 5.9.0-rc4-6-g110da1e703a2 #216 [ 44.087935] Hardware name: Supermicro SYS-7047GR-TRF/X9DRG-QF, BIOS 3.0a 12/05/2013 [ 44.096650] Workqueue: events work_for_cpu_fn [ 44.101644] RIP: 0010:__iommu_dma_unmap+0x115/0x130 [ 44.107225] Code: 48 8b 0c 24 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 48 c7 44 24 20 00 00 00 00 48 c7 44 24 08 ff ff ff ff eb 8d <0f> 0b e9 74 ff ff ff e8 1f 36 66 00 66 66 2e 0f 1f 84 00 00 00 00 [ 44.128443] RSP: :c90002397c38 EFLAGS: 00010206 [ 44.134413] RAX: 0020 RBX: 0008 RCX: [ 44.144487] RDX: 0403 RSI: 82a7fb20 RDI: 888477804f30 [ 44.152613] RBP: fec0 R08: 000fec00 R09: 000fedff [ 44.160733] R10: 0002 R11: 0004 R12: 888270c39000 [ 44.168861] R13: 888472d85ee8 R14: 0008 R15: [ 44.176980] FS: () GS:88847980() knlGS: [ 44.186198] CS: 0010 DS: ES: CR0: 80050033 [ 44.192761] CR2: CR3: 02a20001 CR4: 000606e0 [ 44.200871] Call Trace: [ 44.203716] ? lockdep_hardirqs_on_prepare+0xad/0x180 [ 44.209509] iommu_dma_free+0x18/0x30 [ 44.213734] ioat_free_chan_resources+0x19e/0x300 [ 44.219133] ioat_dma_self_test+0x2a0/0x3d0 [ 44.223964] ioat_pci_probe+0x60e/0x903 [ 44.228387] local_pci_probe+0x42/0x80 [ 44.232721] work_for_cpu_fn+0x16/0x20 [ 44.237037] process_one_work+0x292/0x630 [ 44.241644] ? __schedule+0x344/0x970 [ 44.245868] worker_thread+0x227/0x3e0 [ 44.250185] ? process_one_work+0x630/0x630 [ 44.254989] kthread+0x136/0x150 [ 44.258718] ? kthread_use_mm+0x100/0x100 [ 44.263334] ret_from_fork+0x22/0x30 [ 44.267474] irq event stamp: 1881262 [ 44.271602] hardirqs last enabled at (1881272): [] console_unlock+0x435/0x570 [ 44.281593] hardirqs last disabled at (1881281): [] console_unlock+0x42b/0x570 [ 44.291588] softirqs last enabled at (1747140): [] ioat_cleanup+0x65/0x470 [ 44.301285] softirqs last disabled at (1747144): [] ioat_free_chan_resources+0x6a/0x300 [ 44.312153] ---[ end trace ed0f88fd959a5a39 ]--- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 2020-09-15 09:31, Tvrtko Ursulin wrote: On 15/09/2020 02:47, Lu Baolu wrote: Hi Tvrtko, On 9/14/20 4:04 PM, Tvrtko Ursulin wrote: Hi, On 12/09/2020 04:21, Lu Baolu wrote: Tom Murphy has almost done all the work. His latest patch series was posted here. https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ Thanks a lot! This series is a follow-up with below changes: 1. Add a quirk for the i915 driver issue described in Tom's cover letter. Last week I have copied you on an i915 series which appears to remove the need for this quirk. so if we get those i915 patches reviewed and merged, do you still want to pursue this quirk? It's up to the graphic guys. I don't know the details in i915 driver. I don't think my tests could cover all cases. I am the graphic guy. :) I just need some reviews (internally) for my series and then we can merge it, at which point you don't need the quirk patch any more. I'll try to accelerate this. With regards to testing, you could send your series with my patches on top to our trybot mailing list (intel-gfx-try...@lists.freedesktop.org / https://patchwork.freedesktop.org/project/intel-gfx-trybot/series/?ordering=-last_updated) which would show you if it is still hitting the DMAR issues in i915. 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use bounce buffers" to make the bounce buffer work for untrusted devices. 3. Several cleanups in iommu/vt-d driver after the conversion. With the previous version of the series I hit a problem on Ivybridge where apparently the dma engine width is not respected. At least that is my layman interpretation of the errors. From the older thread: <3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not sufficient for the mapped address (008000) Relevant iommu boot related messages are: <6>[ 0.184234] DMAR: Host address width 36 <6>[ 0.184245] DMAR: DRHD base: 0x00fed9 flags: 0x0 <6>[ 0.184288] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap c020e60262 ecap f0101a <6>[ 0.184308] DMAR: DRHD base: 0x00fed91000 flags: 0x1 <6>[ 0.184337] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a <6>[ 0.184357] DMAR: RMRR base: 0x00d8d28000 end: 0x00d8d46fff <6>[ 0.184377] DMAR: RMRR base: 0x00db00 end: 0x00df1f <6>[ 0.184398] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 <6>[ 0.184414] DMAR-IR: HPET id 0 under DRHD base 0xfed91000 <6>[ 0.184428] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. <6>[ 0.185173] DMAR-IR: Enabled IRQ remapping in x2apic mode <6>[ 0.878934] DMAR: No ATSR found <6>[ 0.878966] DMAR: dmar0: Using Queued invalidation <6>[ 0.879007] DMAR: dmar1: Using Queued invalidation <6>[ 0.915032] DMAR: Intel(R) Virtualization Technology for Directed I/O <6>[ 0.915060] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) <6>[ 0.915084] software IO TLB: mapped [mem 0xc80d4000-0xcc0d4000] (64MB) (Full boot log at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/boot0.txt, failures at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/igt@i915_selftest@l...@blt.html.) Does this look familiar or at least plausible to you? Is this something your new series has fixed? This happens during attaching a domain to device. It has nothing to do with this patch series. I will look into this issue, but not in this email thread context. I am not sure what step is attaching domain to device, but these type messages: <3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not >> sufficient for the mapped address (008000) They definitely appear to happen at runtime, as i915 is getting exercised by userspace. AFAICS this certainly might be related to this series - iommu-dma will constrain IOVA allocation based on the domain geometry that the driver reports, which in this case is set only once when first allocating the domain. Thus it looks like both the dmar_domain->gaw adjustment in prepare_domain_attach_device() and the domain_use_first_level() business in intel_alloc_iova() effectively get lost in this conversion, since the domain geometry never gets updated to reflect those additional constraints. Robin. Regards, Tvrtko ___ iommu mailing list io...@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 2020-09-18 21:47, Logan Gunthorpe wrote: Hi Lu, On 2020-09-11 9:21 p.m., Lu Baolu wrote: Tom Murphy has almost done all the work. His latest patch series was posted here. https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ Thanks a lot! This series is a follow-up with below changes: 1. Add a quirk for the i915 driver issue described in Tom's cover letter. 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use bounce buffers" to make the bounce buffer work for untrusted devices. 3. Several cleanups in iommu/vt-d driver after the conversion. I'm trying to test this on an old Sandy Bridge, but found that I get spammed with warnings on boot. I've put a sample of a few of them below. They all seem to be related to ioat. I had the same issue with Tom's v2 but never saw this on his v1. I think this might have more to do with ioat being totally broken - AFAICS it appears to allocate descriptors with a size of 2MB, but free them with a size of 512KB. Try throwing CONFIG_DMA_API_DEBUG at it to confirm. Robin. Thanks, Logan [ 44.057877] [ cut here ] [ 44.063167] WARNING: CPU: 4 PID: 84 at drivers/iommu/dma-iommu.c:496 __iommu_dma_unmap+0x115/0x130 [ 44.073351] Modules linked in: [ 44.076882] CPU: 4 PID: 84 Comm: kworker/4:1 Tainted: GW 5.9.0-rc4-6-g110da1e703a2 #216 [ 44.087935] Hardware name: Supermicro SYS-7047GR-TRF/X9DRG-QF, BIOS 3.0a 12/05/2013 [ 44.096650] Workqueue: events work_for_cpu_fn [ 44.101644] RIP: 0010:__iommu_dma_unmap+0x115/0x130 [ 44.107225] Code: 48 8b 0c 24 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 48 c7 44 24 20 00 00 00 00 48 c7 44 24 08 ff ff ff ff eb 8d <0f> 0b e9 74 ff ff ff e8 1f 36 66 00 66 66 2e 0f 1f 84 00 00 00 00 [ 44.128443] RSP: :c90002397c38 EFLAGS: 00010206 [ 44.134413] RAX: 0020 RBX: 0008 RCX: [ 44.144487] RDX: 0403 RSI: 82a7fb20 RDI: 888477804f30 [ 44.152613] RBP: fec0 R08: 000fec00 R09: 000fedff [ 44.160733] R10: 0002 R11: 0004 R12: 888270c39000 [ 44.168861] R13: 888472d85ee8 R14: 0008 R15: [ 44.176980] FS: () GS:88847980() knlGS: [ 44.186198] CS: 0010 DS: ES: CR0: 80050033 [ 44.192761] CR2: CR3: 02a20001 CR4: 000606e0 [ 44.200871] Call Trace: [ 44.203716] ? lockdep_hardirqs_on_prepare+0xad/0x180 [ 44.209509] iommu_dma_free+0x18/0x30 [ 44.213734] ioat_free_chan_resources+0x19e/0x300 [ 44.219133] ioat_dma_self_test+0x2a0/0x3d0 [ 44.223964] ioat_pci_probe+0x60e/0x903 [ 44.228387] local_pci_probe+0x42/0x80 [ 44.232721] work_for_cpu_fn+0x16/0x20 [ 44.237037] process_one_work+0x292/0x630 [ 44.241644] ? __schedule+0x344/0x970 [ 44.245868] worker_thread+0x227/0x3e0 [ 44.250185] ? process_one_work+0x630/0x630 [ 44.254989] kthread+0x136/0x150 [ 44.258718] ? kthread_use_mm+0x100/0x100 [ 44.263334] ret_from_fork+0x22/0x30 [ 44.267474] irq event stamp: 1881262 [ 44.271602] hardirqs last enabled at (1881272): [] console_unlock+0x435/0x570 [ 44.281593] hardirqs last disabled at (1881281): [] console_unlock+0x42b/0x570 [ 44.291588] softirqs last enabled at (1747140): [] ioat_cleanup+0x65/0x470 [ 44.301285] softirqs last disabled at (1747144): [] ioat_free_chan_resources+0x6a/0x300 [ 44.312153] ---[ end trace ed0f88fd959a5a39 ]--- [ 44.353963] [ cut here ] [ 44.359291] WARNING: CPU: 4 PID: 84 at drivers/iommu/dma-iommu.c:496 __iommu_dma_unmap+0x115/0x130 [ 44.369482] Modules linked in: [ 44.373030] CPU: 4 PID: 84 Comm: kworker/4:1 Tainted: GW 5.9.0-rc4-6-g110da1e703a2 #216 [ 44.384097] Hardware name: Supermicro SYS-7047GR-TRF/X9DRG-QF, BIOS 3.0a 12/05/2013 [ 44.392825] Workqueue: events work_for_cpu_fn [ 44.397831] RIP: 0010:__iommu_dma_unmap+0x115/0x130 [ 44.403421] Code: 48 8b 0c 24 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 48 c7 44 24 20 00 00 00 00 48 c7 44 24 08 ff ff ff ff eb 8d <0f> 0b e9 74 ff ff ff e8 1f 36 66 00 66 66 2e 0f 1f 84 00 00 00 00 [ 44.424644] RSP: :c90002397c38 EFLAGS: 00010206 [ 44.430627] RAX: 0020 RBX: 0008 RCX: [ 44.438770] RDX: 0403 RSI: 82a7fb20 RDI: 888477804f30 [ 44.446885] RBP: ffc0 R08: 000ffc00 R09: 000ffdff [ 44.455000] R10: 0002 R11: 0004 R12: 888270c55000 [ 44.463119] R13: 888472dc7268 R14: 0008 R15: [ 44.471235] FS: () GS:88847980() knlGS: [ 44.480440] CS: 0010 DS: ES: CR0: 80050033 [ 44.487004] CR2: CR3: 02a20001 CR4: 000606e0 [
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
Hi Logan, On 9/21/20 11:48 PM, Logan Gunthorpe wrote: On 2020-09-20 12:36 a.m., Lu Baolu wrote: Hi Logan, On 2020/9/19 4:47, Logan Gunthorpe wrote: Hi Lu, On 2020-09-11 9:21 p.m., Lu Baolu wrote: Tom Murphy has almost done all the work. His latest patch series was posted here. https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ Thanks a lot! This series is a follow-up with below changes: 1. Add a quirk for the i915 driver issue described in Tom's cover letter. 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use bounce buffers" to make the bounce buffer work for untrusted devices. 3. Several cleanups in iommu/vt-d driver after the conversion. I'm trying to test this on an old Sandy Bridge, but found that I get spammed with warnings on boot. I've put a sample of a few of them below. They all seem to be related to ioat. I had the same issue with Tom's v2 but never saw this on his v1. Have you verified whether this could be reproduced with the lasted upstream kernel (without this patch series)? Yes. I am sorry. Just want to make sure I understand you correctly. :-) When you say "yes", do you mean you could reproduce this with pure upstream kernel (5.9-rc6)? Also, it's hitting a warning in the dma-iommu code which would not be hit without this patch set. Without this series, DMA APIs don't go through dma-iommu. Do you mind posting the warning message? Best regards, baolu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 2020-09-20 12:36 a.m., Lu Baolu wrote: > Hi Logan, > > On 2020/9/19 4:47, Logan Gunthorpe wrote: >> Hi Lu, >> >> On 2020-09-11 9:21 p.m., Lu Baolu wrote: >>> Tom Murphy has almost done all the work. His latest patch series was >>> posted here. >>> >>> https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ >>> >>> Thanks a lot! >>> >>> This series is a follow-up with below changes: >>> >>> 1. Add a quirk for the i915 driver issue described in Tom's cover >>> letter. >>> 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use >>> bounce buffers" to make the bounce buffer work for untrusted devices. >>> 3. Several cleanups in iommu/vt-d driver after the conversion. >>> >> >> I'm trying to test this on an old Sandy Bridge, but found that I get >> spammed with warnings on boot. I've put a sample of a few of them below. >> They all seem to be related to ioat. >> >> I had the same issue with Tom's v2 but never saw this on his v1. > > Have you verified whether this could be reproduced with the lasted > upstream kernel (without this patch series)? Yes. Also, it's hitting a warning in the dma-iommu code which would not be hit without this patch set. Thanks, Logan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
Hi Logan, On 2020/9/19 4:47, Logan Gunthorpe wrote: Hi Lu, On 2020-09-11 9:21 p.m., Lu Baolu wrote: Tom Murphy has almost done all the work. His latest patch series was posted here. https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ Thanks a lot! This series is a follow-up with below changes: 1. Add a quirk for the i915 driver issue described in Tom's cover letter. 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use bounce buffers" to make the bounce buffer work for untrusted devices. 3. Several cleanups in iommu/vt-d driver after the conversion. I'm trying to test this on an old Sandy Bridge, but found that I get spammed with warnings on boot. I've put a sample of a few of them below. They all seem to be related to ioat. I had the same issue with Tom's v2 but never saw this on his v1. Have you verified whether this could be reproduced with the lasted upstream kernel (without this patch series)? Best regards, baolu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
Hi Lu, On 2020-09-11 9:21 p.m., Lu Baolu wrote: > Tom Murphy has almost done all the work. His latest patch series was > posted here. > > https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ > > Thanks a lot! > > This series is a follow-up with below changes: > > 1. Add a quirk for the i915 driver issue described in Tom's cover > letter. > 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use > bounce buffers" to make the bounce buffer work for untrusted devices. > 3. Several cleanups in iommu/vt-d driver after the conversion. > I'm trying to test this on an old Sandy Bridge, but found that I get spammed with warnings on boot. I've put a sample of a few of them below. They all seem to be related to ioat. I had the same issue with Tom's v2 but never saw this on his v1. Thanks, Logan [ 44.057877] [ cut here ] [ 44.063167] WARNING: CPU: 4 PID: 84 at drivers/iommu/dma-iommu.c:496 __iommu_dma_unmap+0x115/0x130 [ 44.073351] Modules linked in: [ 44.076882] CPU: 4 PID: 84 Comm: kworker/4:1 Tainted: GW 5.9.0-rc4-6-g110da1e703a2 #216 [ 44.087935] Hardware name: Supermicro SYS-7047GR-TRF/X9DRG-QF, BIOS 3.0a 12/05/2013 [ 44.096650] Workqueue: events work_for_cpu_fn [ 44.101644] RIP: 0010:__iommu_dma_unmap+0x115/0x130 [ 44.107225] Code: 48 8b 0c 24 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 48 c7 44 24 20 00 00 00 00 48 c7 44 24 08 ff ff ff ff eb 8d <0f> 0b e9 74 ff ff ff e8 1f 36 66 00 66 66 2e 0f 1f 84 00 00 00 00 [ 44.128443] RSP: :c90002397c38 EFLAGS: 00010206 [ 44.134413] RAX: 0020 RBX: 0008 RCX: [ 44.144487] RDX: 0403 RSI: 82a7fb20 RDI: 888477804f30 [ 44.152613] RBP: fec0 R08: 000fec00 R09: 000fedff [ 44.160733] R10: 0002 R11: 0004 R12: 888270c39000 [ 44.168861] R13: 888472d85ee8 R14: 0008 R15: [ 44.176980] FS: () GS:88847980() knlGS: [ 44.186198] CS: 0010 DS: ES: CR0: 80050033 [ 44.192761] CR2: CR3: 02a20001 CR4: 000606e0 [ 44.200871] Call Trace: [ 44.203716] ? lockdep_hardirqs_on_prepare+0xad/0x180 [ 44.209509] iommu_dma_free+0x18/0x30 [ 44.213734] ioat_free_chan_resources+0x19e/0x300 [ 44.219133] ioat_dma_self_test+0x2a0/0x3d0 [ 44.223964] ioat_pci_probe+0x60e/0x903 [ 44.228387] local_pci_probe+0x42/0x80 [ 44.232721] work_for_cpu_fn+0x16/0x20 [ 44.237037] process_one_work+0x292/0x630 [ 44.241644] ? __schedule+0x344/0x970 [ 44.245868] worker_thread+0x227/0x3e0 [ 44.250185] ? process_one_work+0x630/0x630 [ 44.254989] kthread+0x136/0x150 [ 44.258718] ? kthread_use_mm+0x100/0x100 [ 44.263334] ret_from_fork+0x22/0x30 [ 44.267474] irq event stamp: 1881262 [ 44.271602] hardirqs last enabled at (1881272): [] console_unlock+0x435/0x570 [ 44.281593] hardirqs last disabled at (1881281): [] console_unlock+0x42b/0x570 [ 44.291588] softirqs last enabled at (1747140): [] ioat_cleanup+0x65/0x470 [ 44.301285] softirqs last disabled at (1747144): [] ioat_free_chan_resources+0x6a/0x300 [ 44.312153] ---[ end trace ed0f88fd959a5a39 ]--- [ 44.353963] [ cut here ] [ 44.359291] WARNING: CPU: 4 PID: 84 at drivers/iommu/dma-iommu.c:496 __iommu_dma_unmap+0x115/0x130 [ 44.369482] Modules linked in: [ 44.373030] CPU: 4 PID: 84 Comm: kworker/4:1 Tainted: GW 5.9.0-rc4-6-g110da1e703a2 #216 [ 44.384097] Hardware name: Supermicro SYS-7047GR-TRF/X9DRG-QF, BIOS 3.0a 12/05/2013 [ 44.392825] Workqueue: events work_for_cpu_fn [ 44.397831] RIP: 0010:__iommu_dma_unmap+0x115/0x130 [ 44.403421] Code: 48 8b 0c 24 48 c7 44 24 10 00 00 00 00 48 c7 44 24 18 00 00 00 00 48 c7 44 24 20 00 00 00 00 48 c7 44 24 08 ff ff ff ff eb 8d <0f> 0b e9 74 ff ff ff e8 1f 36 66 00 66 66 2e 0f 1f 84 00 00 00 00 [ 44.424644] RSP: :c90002397c38 EFLAGS: 00010206 [ 44.430627] RAX: 0020 RBX: 0008 RCX: [ 44.438770] RDX: 0403 RSI: 82a7fb20 RDI: 888477804f30 [ 44.446885] RBP: ffc0 R08: 000ffc00 R09: 000ffdff [ 44.455000] R10: 0002 R11: 0004 R12: 888270c55000 [ 44.463119] R13: 888472dc7268 R14: 0008 R15: [ 44.471235] FS: () GS:88847980() knlGS: [ 44.480440] CS: 0010 DS: ES: CR0: 80050033 [ 44.487004] CR2: CR3: 02a20001 CR4: 000606e0 [ 44.495128] Call Trace: [ 44.498008] iommu_dma_free+0x18/0x30 [ 44.502230] ioat_free_chan_resources+0x19e/0x300 [ 44.507631] ioat_dma_self_test+0x2a0/0x3d0 [ 44.512466] ioat_pci_probe+0x60e/0x903 [ 44.516889] local_pci_probe+0x42/0x80 [
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 15/09/2020 02:47, Lu Baolu wrote: Hi Tvrtko, On 9/14/20 4:04 PM, Tvrtko Ursulin wrote: Hi, On 12/09/2020 04:21, Lu Baolu wrote: Tom Murphy has almost done all the work. His latest patch series was posted here. https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ Thanks a lot! This series is a follow-up with below changes: 1. Add a quirk for the i915 driver issue described in Tom's cover letter. Last week I have copied you on an i915 series which appears to remove the need for this quirk. so if we get those i915 patches reviewed and merged, do you still want to pursue this quirk? It's up to the graphic guys. I don't know the details in i915 driver. I don't think my tests could cover all cases. I am the graphic guy. :) I just need some reviews (internally) for my series and then we can merge it, at which point you don't need the quirk patch any more. I'll try to accelerate this. With regards to testing, you could send your series with my patches on top to our trybot mailing list (intel-gfx-try...@lists.freedesktop.org / https://patchwork.freedesktop.org/project/intel-gfx-trybot/series/?ordering=-last_updated) which would show you if it is still hitting the DMAR issues in i915. 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use bounce buffers" to make the bounce buffer work for untrusted devices. 3. Several cleanups in iommu/vt-d driver after the conversion. With the previous version of the series I hit a problem on Ivybridge where apparently the dma engine width is not respected. At least that is my layman interpretation of the errors. From the older thread: <3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not sufficient for the mapped address (008000) Relevant iommu boot related messages are: <6>[ 0.184234] DMAR: Host address width 36 <6>[ 0.184245] DMAR: DRHD base: 0x00fed9 flags: 0x0 <6>[ 0.184288] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap c020e60262 ecap f0101a <6>[ 0.184308] DMAR: DRHD base: 0x00fed91000 flags: 0x1 <6>[ 0.184337] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a <6>[ 0.184357] DMAR: RMRR base: 0x00d8d28000 end: 0x00d8d46fff <6>[ 0.184377] DMAR: RMRR base: 0x00db00 end: 0x00df1f <6>[ 0.184398] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 <6>[ 0.184414] DMAR-IR: HPET id 0 under DRHD base 0xfed91000 <6>[ 0.184428] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. <6>[ 0.185173] DMAR-IR: Enabled IRQ remapping in x2apic mode <6>[ 0.878934] DMAR: No ATSR found <6>[ 0.878966] DMAR: dmar0: Using Queued invalidation <6>[ 0.879007] DMAR: dmar1: Using Queued invalidation <6>[ 0.915032] DMAR: Intel(R) Virtualization Technology for Directed I/O <6>[ 0.915060] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) <6>[ 0.915084] software IO TLB: mapped [mem 0xc80d4000-0xcc0d4000] (64MB) (Full boot log at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/boot0.txt, failures at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/igt@i915_selftest@l...@blt.html.) Does this look familiar or at least plausible to you? Is this something your new series has fixed? This happens during attaching a domain to device. It has nothing to do with this patch series. I will look into this issue, but not in this email thread context. I am not sure what step is attaching domain to device, but these type messages: <3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not >> sufficient for the mapped address (008000) They definitely appear to happen at runtime, as i915 is getting exercised by userspace. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
Hi Tvrtko, On 9/14/20 4:04 PM, Tvrtko Ursulin wrote: Hi, On 12/09/2020 04:21, Lu Baolu wrote: Tom Murphy has almost done all the work. His latest patch series was posted here. https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ Thanks a lot! This series is a follow-up with below changes: 1. Add a quirk for the i915 driver issue described in Tom's cover letter. Last week I have copied you on an i915 series which appears to remove the need for this quirk. so if we get those i915 patches reviewed and merged, do you still want to pursue this quirk? It's up to the graphic guys. I don't know the details in i915 driver. I don't think my tests could cover all cases. 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use bounce buffers" to make the bounce buffer work for untrusted devices. 3. Several cleanups in iommu/vt-d driver after the conversion. With the previous version of the series I hit a problem on Ivybridge where apparently the dma engine width is not respected. At least that is my layman interpretation of the errors. From the older thread: <3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not sufficient for the mapped address (008000) Relevant iommu boot related messages are: <6>[0.184234] DMAR: Host address width 36 <6>[0.184245] DMAR: DRHD base: 0x00fed9 flags: 0x0 <6>[0.184288] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap c020e60262 ecap f0101a <6>[0.184308] DMAR: DRHD base: 0x00fed91000 flags: 0x1 <6>[0.184337] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a <6>[0.184357] DMAR: RMRR base: 0x00d8d28000 end: 0x00d8d46fff <6>[0.184377] DMAR: RMRR base: 0x00db00 end: 0x00df1f <6>[0.184398] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 <6>[0.184414] DMAR-IR: HPET id 0 under DRHD base 0xfed91000 <6>[0.184428] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. <6>[0.185173] DMAR-IR: Enabled IRQ remapping in x2apic mode <6>[0.878934] DMAR: No ATSR found <6>[0.878966] DMAR: dmar0: Using Queued invalidation <6>[0.879007] DMAR: dmar1: Using Queued invalidation <6>[0.915032] DMAR: Intel(R) Virtualization Technology for Directed I/O <6>[0.915060] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) <6>[0.915084] software IO TLB: mapped [mem 0xc80d4000-0xcc0d4000] (64MB) (Full boot log at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/boot0.txt, failures at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/igt@i915_selftest@l...@blt.html.) Does this look familiar or at least plausible to you? Is this something your new series has fixed? This happens during attaching a domain to device. It has nothing to do with this patch series. I will look into this issue, but not in this email thread context. Best regards, baolu Regards, Tvrtko Please review and test. Best regards, baolu Lu Baolu (2): iommu: Add quirk for Intel graphic devices in map_sg iommu/vt-d: Cleanup after converting to dma-iommu ops Tom Murphy (4): iommu: Handle freelists when using deferred flushing in iommu drivers iommu: Add iommu_dma_free_cpu_cached_iovas() iommu: Allow the dma-iommu api to use bounce buffers iommu/vt-d: Convert intel iommu driver to the iommu ops .../admin-guide/kernel-parameters.txt | 5 - drivers/iommu/dma-iommu.c | 229 - drivers/iommu/intel/Kconfig | 1 + drivers/iommu/intel/iommu.c | 885 +++--- include/linux/dma-iommu.h | 8 + include/linux/iommu.h | 1 + 6 files changed, 323 insertions(+), 806 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
Hi, On 12/09/2020 04:21, Lu Baolu wrote: > Tom Murphy has almost done all the work. His latest patch series was > posted here. > > https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ > > Thanks a lot! > > This series is a follow-up with below changes: > > 1. Add a quirk for the i915 driver issue described in Tom's cover > letter. Last week I have copied you on an i915 series which appears to remove the need for this quirk. so if we get those i915 patches reviewed and merged, do you still want to pursue this quirk? > 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use > bounce buffers" to make the bounce buffer work for untrusted devices. > 3. Several cleanups in iommu/vt-d driver after the conversion. With the previous version of the series I hit a problem on Ivybridge where apparently the dma engine width is not respected. At least that is my layman interpretation of the errors. From the older thread: <3> [209.526605] DMAR: intel_iommu_map: iommu width (39) is not sufficient for the mapped address (008000) Relevant iommu boot related messages are: <6>[0.184234] DMAR: Host address width 36 <6>[0.184245] DMAR: DRHD base: 0x00fed9 flags: 0x0 <6>[0.184288] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap c020e60262 ecap f0101a <6>[0.184308] DMAR: DRHD base: 0x00fed91000 flags: 0x1 <6>[0.184337] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a <6>[0.184357] DMAR: RMRR base: 0x00d8d28000 end: 0x00d8d46fff <6>[0.184377] DMAR: RMRR base: 0x00db00 end: 0x00df1f <6>[0.184398] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1 <6>[0.184414] DMAR-IR: HPET id 0 under DRHD base 0xfed91000 <6>[0.184428] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping. <6>[0.185173] DMAR-IR: Enabled IRQ remapping in x2apic mode <6>[0.878934] DMAR: No ATSR found <6>[0.878966] DMAR: dmar0: Using Queued invalidation <6>[0.879007] DMAR: dmar1: Using Queued invalidation <6>[0.915032] DMAR: Intel(R) Virtualization Technology for Directed I/O <6>[0.915060] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) <6>[0.915084] software IO TLB: mapped [mem 0xc80d4000-0xcc0d4000] (64MB) (Full boot log at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/boot0.txt, failures at https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_7054/fi-ivb-3770/igt@i915_selftest@l...@blt.html.) Does this look familiar or at least plausible to you? Is this something your new series has fixed? Regards, Tvrtko > > Please review and test. > > Best regards, > baolu > > Lu Baolu (2): >iommu: Add quirk for Intel graphic devices in map_sg >iommu/vt-d: Cleanup after converting to dma-iommu ops > > Tom Murphy (4): >iommu: Handle freelists when using deferred flushing in iommu drivers >iommu: Add iommu_dma_free_cpu_cached_iovas() >iommu: Allow the dma-iommu api to use bounce buffers >iommu/vt-d: Convert intel iommu driver to the iommu ops > > .../admin-guide/kernel-parameters.txt | 5 - > drivers/iommu/dma-iommu.c | 229 - > drivers/iommu/intel/Kconfig | 1 + > drivers/iommu/intel/iommu.c | 885 +++--- > include/linux/dma-iommu.h | 8 + > include/linux/iommu.h | 1 + > 6 files changed, 323 insertions(+), 806 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
