RE: [PATCH] Documentation: x86: rework IOMMU documentation
[Public] > -Original Message- > From: Jacob Pan > Sent: Tuesday, April 26, 2022 12:45 PM > To: Deucher, Alexander > Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; > cor...@lwn.net; h...@zytor.com; x...@kernel.org; > dave.han...@linux.intel.com; b...@alien8.de; mi...@redhat.com; > t...@linutronix.de; j...@8bytes.org; Suthikulpanit, Suravee > ; w...@kernel.org; iommu@lists.linux- > foundation.org; robin.mur...@arm.com; Hegde, Vasant > ; jacob.jun@intel.com; Lu, Baolu > > Subject: Re: [PATCH] Documentation: x86: rework IOMMU documentation > > Hi Alex, > > Thanks for doing this, really helps to catch up the current state. Please see > my > comments inline. > > On Fri, 22 Apr 2022 16:06:07 -0400, Alex Deucher > wrote: > > > Add preliminary documentation for AMD IOMMU and combine with the > > existing Intel IOMMU documentation and clean up and modernize some of > > the existing documentation to align with the current state of the > > kernel. > > > > Signed-off-by: Alex Deucher > > --- > > > > V2: Incorporate feedback from Robin to clarify IOMMU vs DMA engine (e.g., > > a device) and document proper DMA API. Also correct the fact that > > the AMD IOMMU is not limited to managing PCI devices. > > v3: Fix spelling and rework text as suggested by Vasant > > v4: Combine Intel and AMD documents into a single document as suggested > > by Dave Hansen > > v5: Clarify that keywords are related to ACPI, grammatical fixes > > v6: Make more stuff common based on feedback from Robin > > > > Documentation/x86/index.rst | 2 +- > > Documentation/x86/intel-iommu.rst | 115 > > Documentation/x86/iommu.rst | 143 > ++ > > 3 files changed, 144 insertions(+), 116 deletions(-) delete mode > > 100644 Documentation/x86/intel-iommu.rst create mode 100644 > > Documentation/x86/iommu.rst > > > > diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst > > index f498f1d36cd3..6f8409fe0674 100644 > > --- a/Documentation/x86/index.rst > > +++ b/Documentation/x86/index.rst > > @@ -21,7 +21,7 @@ x86-specific Documentation > > tlb > > mtrr > > pat > > - intel-iommu > > + iommu > > intel_txt > > amd-memory-encryption > > pti > > diff --git a/Documentation/x86/intel-iommu.rst > > b/Documentation/x86/intel-iommu.rst deleted file mode 100644 index > > 099f13d51d5f.. > > --- a/Documentation/x86/intel-iommu.rst > > +++ /dev/null > > @@ -1,115 +0,0 @@ > > -=== > > -Linux IOMMU Support > > -=== > > - > > -The architecture spec can be obtained from the below location. > > - > > - > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. > > > intel.com%2Fcontent%2Fdam%2Fwww%2Fpublic%2Fus%2Fen%2Fdocuments > %2Fprodu > > ct-specifications%2Fvt-directed-io- > spec.pdfdata=05%7C01%7Calexand > > > er.deucher%40amd.com%7C929847a4b2524432d1a608da27a3c9b0%7C3dd > 8961fe488 > > > 4e608e11a82d994e183d%7C0%7C0%7C637865881851295857%7CUnknow > n%7CTWFpbGZs > > > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3D > > > %7C3000%7C%7C%7Csdata=KaPkvBSHWbn1cKBRzyk9H%2BuNDll%2Bq > 3wPfR3SFVA > > LwkU%3Dreserved=0 > > - > > -This guide gives a quick cheat sheet for some basic understanding. > > - > > -Some Keywords > > - > > -- DMAR - DMA remapping > > -- DRHD - DMA Remapping Hardware Unit Definition > > -- RMRR - Reserved memory Region Reporting Structure > > -- ZLR - Zero length reads from PCI devices > > -- IOVA - IO Virtual address. > > - > I feel this combined document only focus on IOVA and DMA APIs, it is > considered as legacy DMA after scalable mode is introduced by Intel to > support DMA with PASID, shared virtual addressing (SVA). > Perhaps, we can also combine ./Documentation/x86/sva.rst I think it would make sense to take that up in a separate patch set. > > With scalable mode, it affects boot messages, fault reporting, etc. I am not > saying no to this document, just suggesting. I don't know where AMD is at in > terms of PASID support but there are lots of things in common between VT-d > and ARM's SMMU in terms of PASID/SVA. Should we broaden the purpose of > this document even further? I think that would make sense for a future clean up. I'd like to land the current clean up first. AMD's IOMMU driver has supported PASID for probably 8-10 years. When we originally added it no other vendors were interested in supporting it so we made it a private API which was used by other AMD drivers that needed it at the time. Suravee can probably comment on the status of our support for the cross vendor API. Alex > > > -Basic stuff > > > > - > > -ACPI enumerates and lists the different DMA engines in the platform, > > and -device scope relationships between PCI devices and which DMA > > engine controls -them. > > - > > -What is RMRR? > > -- > > - > > -There are some devices the BIOS
RE: [PATCH v4] Documentation: x86: rework IOMMU documentation
[Public] > -Original Message- > From: Robin Murphy > Sent: Friday, April 22, 2022 3:41 PM > To: Deucher, Alexander ; linux- > d...@vger.kernel.org; linux-ker...@vger.kernel.org; cor...@lwn.net; > h...@zytor.com; x...@kernel.org; dave.han...@linux.intel.com; > b...@alien8.de; mi...@redhat.com; t...@linutronix.de; j...@8bytes.org; > Suthikulpanit, Suravee ; w...@kernel.org; > iommu@lists.linux-foundation.org; Hegde, Vasant > Subject: Re: [PATCH v4] Documentation: x86: rework IOMMU documentation > > On 2022-04-22 18:54, Alex Deucher wrote: > [...] > > +Intel Specific Notes > > + > > + > > +Graphics Problems? > > +^^ > > + > > +If you encounter issues with graphics devices, you can try adding > > +option intel_iommu=igfx_off to turn off the integrated graphics engine. > > +If this fixes anything, please ensure you file a bug reporting the problem. > > + > > +Some exceptions to IOVA > > +^^^ > > + > > +Interrupt ranges are not address translated, (0xfee0 - 0xfeef). > > +The same is true for peer to peer transactions. Hence we reserve the > > +address from PCI MMIO ranges so they are not allocated for IOVA > addresses. > > Note that this should be true for both drivers. > > > + > > +AMD Specific Notes > > +-- > > + > > +Graphics Problems? > > +^^ > > + > > +If you encounter issues with integrated graphics devices, you can try > > +adding option iommu=pt to the kernel command line use a 1:1 mapping > > +for the IOMMU. If this fixes anything, please ensure you file a bug > reporting the problem. > > And indeed this is a generic option. I reckon we could simply merge these two > sections together, with the first paragraph being something like: > > If you encounter issues with integrated graphics devices, you can try adding > the option "iommu.passthrough=1", or the equivalent "iommu=pt", to the > kernel command line to use a 1:1 mapping for the IOMMU in general. On > Intel you can also try "intel_iommu=igfx_off" to turn off translation > specifically > for the integrated graphics engine only. If this fixes anything, please > ensure > you file a bug reporting the problem. > > > + > > +Fault reporting > > +--- > > +When errors are reported, the IOMMU signals via an interrupt. The > > +fault reason and device that caused it is printed on the console. > > + > > + > > +Kernel Log Samples > > +-- > > + > > +Intel Boot Messages > > +^^^ > > + > > +Something like this gets printed indicating presence of DMAR tables > > +in ACPI. > > + > > +:: > > + > > + ACPI: DMAR (v001 A M I OEMDMAR 0x0001 MSFT > 0x0097) @ > > +0x7f5b5ef0 > > + > > +When DMAR is being processed and initialized by ACPI, prints DMAR > > +locations and any RMRR's processed > > + > > +:: > > + > > + ACPI DMAR:Host address width 36 > > + ACPI DMAR:DRHD (flags: 0x)base: 0xfed9 > > + ACPI DMAR:DRHD (flags: 0x)base: 0xfed91000 > > + ACPI DMAR:DRHD (flags: 0x0001)base: 0xfed93000 > > + ACPI DMAR:RMRR base: 0x000ed000 end: > 0x000e > > + ACPI DMAR:RMRR base: 0x7f60 end: > 0x7fff > > + > > +When DMAR is enabled for use, you will notice > > + > > +:: > > + > > + PCI-DMA: Using DMAR IOMMU > > + > > +Intel Fault reporting > > +^ > > + > > +:: > > + > > + DMAR:[DMA Write] Request device [00:02.0] fault addr 6df084000 > > + DMAR:[fault reason 05] PTE Write access is not set > > + DMAR:[DMA Write] Request device [00:02.0] fault addr 6df084000 > > + DMAR:[fault reason 05] PTE Write access is not set > > + > > +AMD Boot Messages > > +^ > > + > > +Something like this gets printed indicating presence of the IOMMU. > > + > > +:: > > + > > + iommu: Default domain type: Translated > > + iommu: DMA domain TLB invalidation policy: lazy mode > > Similarly, that's common IOMMU API reporting which will be seen on all > architectures (let alone IOMMU drivers). Maybe some of the messages from > print_iommu_info() might be better AMD-specific examples? > All good points. I've integrated these suggestions and will send out a new version. Thanks! Alex > Cheers, > Robin. > > > + > > +AMD Fault reporting > > +^^^ > > + > > +:: > > + > > + AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0007 > address=0xc02000 flags=0x] > > + AMD-Vi: Event logged [IO_PAGE_FAULT device=07:00.0 > domain=0x0007 > > +address=0xc02000 flags=0x] ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH v4] Documentation: x86: rework IOMMU documentation
[Public] > -Original Message- > From: Deucher, Alexander > Sent: Friday, April 22, 2022 1:54 PM > To: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; > cor...@lwn.net; h...@zytor.com; x...@kernel.org; > dave.han...@linux.intel.com; b...@alien8.de; mi...@redhat.com; > t...@linutronix.de; j...@8bytes.org; Suthikulpanit, Suravee > ; w...@kernel.org; iommu@lists.linux- > foundation.org; robin.mur...@arm.com; Hegde, Vasant > > Cc: Deucher, Alexander > Subject: [PATCH v4] Documentation: x86: rework IOMMU documentation > > Add preliminary documentation for AMD IOMMU and combine with the > existing Intel IOMMU documentation and clean up and modernize some of the > existing documentation to align with the current state of the kernel. > > Signed-off-by: Alex Deucher > --- > > V2: Incorporate feedback from Robin to clarify IOMMU vs DMA engine (e.g., > a device) and document proper DMA API. Also correct the fact that > the AMD IOMMU is not limited to managing PCI devices. > v3: Fix spelling and rework text as suggested by Vasant > v4: Combine Intel and AMD documents into a single document as suggested > by Dave Hansen > > Documentation/x86/index.rst | 2 +- > Documentation/x86/intel-iommu.rst | 115 -- > Documentation/x86/iommu.rst | 153 > ++ > 3 files changed, 154 insertions(+), 116 deletions(-) delete mode 100644 > Documentation/x86/intel-iommu.rst create mode 100644 > Documentation/x86/iommu.rst > > diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst > index f498f1d36cd3..6f8409fe0674 100644 > --- a/Documentation/x86/index.rst > +++ b/Documentation/x86/index.rst > @@ -21,7 +21,7 @@ x86-specific Documentation > tlb > mtrr > pat > - intel-iommu > + iommu > intel_txt > amd-memory-encryption > pti > diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel- > iommu.rst > deleted file mode 100644 > index 099f13d51d5f.. > --- a/Documentation/x86/intel-iommu.rst > +++ /dev/null > @@ -1,115 +0,0 @@ > -=== > -Linux IOMMU Support > -=== > - > -The architecture spec can be obtained from the below location. > - > -http://www.intel.com/content/dam/www/public/us/en/documents/product- > specifications/vt-directed-io-spec.pdf > - > -This guide gives a quick cheat sheet for some basic understanding. > - > -Some Keywords > - > -- DMAR - DMA remapping > -- DRHD - DMA Remapping Hardware Unit Definition > -- RMRR - Reserved memory Region Reporting Structure > -- ZLR - Zero length reads from PCI devices > -- IOVA - IO Virtual address. > - > -Basic stuff > > - > -ACPI enumerates and lists the different DMA engines in the platform, and - > device scope relationships between PCI devices and which DMA engine > controls -them. > - > -What is RMRR? > -- > - > -There are some devices the BIOS controls, for e.g USB devices to perform > -PS2 emulation. The regions of memory used for these devices are marked - > reserved in the e820 map. When we turn on DMA translation, DMA to those - > regions will fail. Hence BIOS uses RMRR to specify these regions along with - > devices that need to access these regions. OS is expected to setup -unity > mappings for these regions for these devices to access these regions. > - > -How is IOVA generated? > --- > - > -Well behaved drivers call pci_map_*() calls before sending command to > device -that needs to perform DMA. Once DMA is completed and mapping is > no longer -required, device performs a pci_unmap_*() calls to unmap the > region. > - > -The Intel IOMMU driver allocates a virtual address per domain. Each PCIE - > device has its own domain (hence protection). Devices under p2p bridges - > share the virtual address with all devices under the p2p bridge due to - > transaction id aliasing for p2p bridges. > - > -IOVA generation is pretty generic. We used the same technique as vmalloc() - > but these are not global address spaces, but separate for each domain. > -Different DMA engines may support different number of domains. > - > -We also allocate guard pages with each mapping, so we can attempt to catch - > any overflow that might happen. > - > - > -Graphics Problems? > --- > -If you encounter issues with graphics devices, you can try adding -option > intel_iommu=igfx_off to turn off the integrated graphics engine. > -If this fixes anything, please ensure you file a bug reporting the problem. > - > -Some exceptions to IOVA > > -Interrupt ranges are not address translated, (0xfee0 - 0xfeef). > -The same is true for peer to peer transactions. Hence we reserve the - > address from PCI MMIO ranges so they are not allocated for IOVA addresses. > - > - > -Fault reporting > > -When errors are reported, the DMA engine signals via an interrupt. The fault > -reason and device that caused it with
RE: [PATCH V3 1/2] Documentation: x86: Add documentation for AMD IOMMU
[Public] > -Original Message- > From: Dave Hansen > Sent: Tuesday, March 29, 2022 11:25 AM > To: Deucher, Alexander ; linux- > d...@vger.kernel.org; linux-ker...@vger.kernel.org; cor...@lwn.net; > h...@zytor.com; x...@kernel.org; dave.han...@linux.intel.com; > b...@alien8.de; mi...@redhat.com; t...@linutronix.de; j...@8bytes.org; > Suthikulpanit, Suravee ; w...@kernel.org; > iommu@lists.linux-foundation.org; robin.mur...@arm.com; Hegde, Vasant > > Subject: Re: [PATCH V3 1/2] Documentation: x86: Add documentation for > AMD IOMMU > > On 3/28/22 10:28, Alex Deucher wrote: > > +How is IOVA generated? > > +-- > > + > > +Well behaved drivers call dma_map_*() calls before sending command to > > +device that needs to perform DMA. Once DMA is completed and mapping > > +is no longer required, driver performs dma_unmap_*() calls to unmap the > region. > > + > > +Fault reporting > > +--- > > + > > +When errors are reported, the IOMMU signals via an interrupt. The > > +fault reason and device that caused it is printed on the console. > > Just scanning this, it looks *awfully* generic. Is anything in here AMD- > specific? Should this be in an AMD-specific file? There is some information about the ACPI tables used to enumerate the IOMMUs and a link to the AMD IOMMU programming documentation. Would you prefer I just create a combined x86 IOMMU document? Alex ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH] Documentation: x86: add documenation for AMD IOMMU
[Public] > -Original Message- > From: Robin Murphy > Sent: Tuesday, March 8, 2022 3:09 PM > To: Deucher, Alexander ; linux- > d...@vger.kernel.org; linux-ker...@vger.kernel.org; cor...@lwn.net; > h...@zytor.com; x...@kernel.org; dave.han...@linux.intel.com; > b...@alien8.de; mi...@redhat.com; t...@linutronix.de; j...@8bytes.org; > Suthikulpanit, Suravee ; w...@kernel.org; > iommu@lists.linux-foundation.org > Subject: Re: [PATCH] Documentation: x86: add documenation for AMD > IOMMU > > On 2022-03-08 19:04, Alex Deucher via iommu wrote: > > Add preliminary documenation for AMD IOMMU. > > > > Signed-off-by: Alex Deucher > > --- > > Documentation/x86/amd-iommu.rst | 85 > +++ > > Documentation/x86/index.rst | 1 + > > Documentation/x86/intel-iommu.rst | 2 +- > > 3 files changed, 87 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/x86/amd-iommu.rst > > > > diff --git a/Documentation/x86/amd-iommu.rst > > b/Documentation/x86/amd-iommu.rst new file mode 100644 index > > ..89820140fefa > > --- /dev/null > > +++ b/Documentation/x86/amd-iommu.rst > > @@ -0,0 +1,85 @@ > > += > > +AMD IOMMU Support > > += > > + > > +The architecture spec can be obtained from the below location. > > + > > > +https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > ww > > > +.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F48882_IOMMU.pdfda > ta=04%7C > > > +01%7Calexander.deucher%40amd.com%7C3adb51f8c3f1435e0deb08da013f > 8172%7 > > > +C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637823669974023501 > %7CUnkn > > > +own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > k1haWw > > > +iLCJXVCI6Mn0%3D%7C3000sdata=9Wq07GM%2BdT9xt%2FCZ3xhue > %2BrNIe6CnD > > +cG32kwqosUEZ8%3Dreserved=0 > > + > > +This guide gives a quick cheat sheet for some basic understanding. > > + > > +Some Keywords > > + > > +- IVRS - I/O Virtualization Reporting Structure > > +- IVDB - I/O Virtualization Definition Block > > +- IVHD - I/O Virtualization Hardware Definition > > +- IOVA - I/O Virtual Address. > > + > > +Basic stuff > > +--- > > + > > +ACPI enumerates and lists the different DMA engines in the platform, > > +and device scope relationships between PCI devices and which DMA > > +engine controls them. > > "DMA engine" typically means a dedicated device for peripheral-to-memory > or memory-to-memory transfers, or the responsible block within a general > DMA-capable endpoint. In the context of the original Intel doc from whence I > see this is copied, this probably should have said "DMAR unit" > or similar; here I'd suggest picking your favourite vendor-appropriate term > for "instance of IOMMU translation hardware". Let's not promote confusion > more than necessary. > > > + > > +What is IVRS? > > +- > > + > > +The architecture defines an ACPI-compatible data structure called an > > +I/O Virtualization Reporting Structure (IVRS) that is used to convey > > +information related to I/O virtualization to system software. The > > +IVRS describes the configuration and capabilities of the IOMMUs > > +contained in the platform as well as information about the devices that > each IOMMU virtualizes. > > + > > +The IVRS provides information about the following: > > +- IOMMUs present in the platform including their capabilities and > > +proper configuration > > +- System I/O topology relevant to each IOMMU > > +- Peripheral devices that cannot be otherwise enumerated > > +- Memory regions used by SMI/SMM, platform firmware, and platform > > +hardware. These are generally exclusion ranges to be configured by > system software. > > + > > +How is IOVA generated? > > +-- > > + > > +Well behaved drivers call pci_map_*() calls before sending command to > > +device > > Horribly out-of-date drivers call pci_map_*(). Modern well-behaved drivers > call dma_map_*() ;) > > > +that needs to perform DMA. Once DMA is completed and mapping is no > > +longer required, device performs a pci_unmap_*() calls to unmap the > region. > > + > > +The AMD IOMMU driver allocates a virtual address per domain. Each > > +PCIE device has its own domain (hence protection). Devices under p2p > > +bridges share the virtual address with all devices under the p2p > > +bridge due to transaction id aliasing for p2p bridges. > > + > > +IOVA generation is pretty generic. We used the same technique as > > +vmalloc() but these are not global address spaces, but separate for each > domain. > > +Different DMA engines may support different number of domains. > > I'm not sure about this whole section, really - IOVA management was entirely > decoupled from drivers some time ago. If there's value in having some > overview documentation, then it's probably worth consolidating into a > common "IOMMU API" doc that can be cross-referenced for a summary of > domains, groups, and iommu_dma_ops. > > > + > > + > > +Fault reporting > >
RE: [PATCH] iommu/iova: kmemleak when disable SRIOV.
[Public]
> -Original Message-
> From: Zhou, Peng Ju
> Sent: Tuesday, August 3, 2021 1:51 AM
> To: Chris Wilson ; Robin Murphy
> ; iommu@lists.linux-foundation.org
> Cc: Deucher, Alexander ; Wang, Yin
> ; w...@kernel.org; Chang, HaiJun
> ; Deng, Emily
> Subject: RE: [PATCH] iommu/iova: kmemleak when disable SRIOV.
>
> [AMD Official Use Only]
>
> Hi Chris
> I hit kmemleak with your following patch, Can you help to fix it?
>
> According to the info in this thread, it seems the patch doesn't merge into
> iommu mainline branch, but I can get your patch from my kernel: 5.11.0
If this patch is not upstream, it probably ended up in our tree via drm-tip or
drm-misc last time we synced up. If that is the case and the patch is not
upstream, you can just revert the patch from our tree.
Alex
>
>
> commit 48a64dd561a53fb809e3f2210faf5dd442cfc56d
> Author: Chris Wilson
> Date: Sat Jan 16 11:10:35 2021 +
>
> iommu/iova: Use bottom-up allocation for DMA32
>
> Since DMA32 allocations are currently allocated top-down from the 4G
> boundary, this causes fragmentation and reduces the maximise allocation
> size. On some systems, the dma address space may be extremely
> constrained by PCIe windows, requiring a stronger anti-fragmentation
> strategy.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2929
> Signed-off-by: Chris Wilson
>
>
> --
> BW
> Pengju Zhou
>
>
>
>
>
> > -Original Message-
> > From: Robin Murphy
> > Sent: Tuesday, July 27, 2021 10:23 PM
> > To: Zhou, Peng Ju ; iommu@lists.linux-
> > foundation.org
> > Cc: Deucher, Alexander ; Wang, Yin
> > ; w...@kernel.org
> > Subject: Re: [PATCH] iommu/iova: kmemleak when disable SRIOV.
> >
> > On 2021-07-27 15:05, Zhou, Peng Ju wrote:
> > > [AMD Official Use Only]
> > >
> > > Hi Robin
> > > The patch which add "head" :
> > >
> > > commit 48a64dd561a53fb809e3f2210faf5dd442cfc56d
> > > Author: Chris Wilson
> > > Date: Sat Jan 16 11:10:35 2021 +
> > >
> > > iommu/iova: Use bottom-up allocation for DMA32
> > >
> > > Since DMA32 allocations are currently allocated top-down from the 4G
> > > boundary, this causes fragmentation and reduces the maximise
> allocation
> > > size. On some systems, the dma address space may be extremely
> > > constrained by PCIe windows, requiring a stronger anti-fragmentation
> > > strategy.
> > >
> > > Closes:
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> b.f
> > reedesktop.org%2Fdrm%2Fintel%2F-
> >
> %2Fissues%2F2929data=04%7C01%7CPengJu.Zhou%40amd.com%7C4
> 7f
> >
> c4308f6044a379ed908d9510a19b1%7C3dd8961fe4884e608e11a82d994e183d
> >
> %7C0%7C0%7C637629927137121754%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> o
> >
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C20
> 00
> >
> sdata=iO5%2FKSW8KV1UZtwGU3oiZpYqiR4eBNcSpF3%2Ft6uSDpY%3D
> &
> > amp;reserved=0
> > > Signed-off-by: Chris Wilson
> >
> > ...which is not in mainline. I've never even seen it posted for review.
> > In fact two search engines can't seem to find any trace of that SHA or patch
> > subject on the internet at all.
> >
> > By all means tell Chris that his patch, wherever you got it from, is broken,
> but
> > once again there's nothing the upstream maintainers/reviewers can do
> about
> > code which isn't upstream.
> >
> > Thanks,
> > Robin.
> >
> > > --
> > > BW
> > > Pengju Zhou
> > >
> > >
> > >
> > >> -Original Message-
> > >> From: Robin Murphy
> > >> Sent: Tuesday, July 27, 2021 4:52 PM
> > >> To: Zhou, Peng Ju ; iommu@lists.linux-
> > >> foundation.org
> > >> Cc: Deucher, Alexander ; Wang, Yin
> > >> ; w...@kernel.org
> > >> Subject: Re: [PATCH] iommu/iova: kmemleak when disable SRIOV.
> > >>
> > >> On 2021-07-27 05:46, Zhou, Peng Ju wrote:
> > >>> [AMD Official Use Only]
> > >>>
> > >>> Hi Robin
> > >>> 1. it is not a good manner to free a statically allocated object(in
> > >>> this case, it
> > >> is iovad->head) dynamically even though the free only occurred when
> > >> shut down the OS in most cases.
> > >>> 2. the kmemleak occurred when disable SRIOV(remove a PCIE device),
> I
> > >>> post the log in the following, in the log, the line:" kmemleak:
> > >>> Found object by alias at 0x9221ae647050" means the OS frees a
> > >>> not existing object(iovad->head) which added to RB_TREE in the
> > >>> function init_iova_domain
> > >>
> > >> Sure, it was apparent enough what the bug was; my point is that the
> > >> bug does not exist in mainline. This is the current mainline
> > >> definition of struct
> > >> iova_domain:
> > >>
> > >>
> > >> /* holds all the iova translations for a domain */ struct iova_domain {
> > >> spinlock_t iova_rbtree_lock; /* Lock to protect update of rbtree
> > >> */
> > >> struct rb_root rbroot; /* iova domain
RE: [PATCH] iommu/amd: Fix section mismatch warning for detect_ivrs()
[AMD Public Use]
> -Original Message-
> From: Joerg Roedel
> Sent: Tuesday, June 8, 2021 8:29 AM
> To: Joerg Roedel ; Will Deacon
> Cc: Deucher, Alexander ;
> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org; Joerg
> Roedel
> Subject: [PATCH] iommu/amd: Fix section mismatch warning for
> detect_ivrs()
>
> From: Joerg Roedel
>
> A recent commit introduced this section mismatch warning:
>
> WARNING: modpost: vmlinux.o(.text.unlikely+0x22a1f): Section
> mismatch in reference from the function detect_ivrs() to the variable
> .init.data:amd_iommu_force_enable
>
> The reason is that detect_ivrs() is not marked __init while it should be,
> because it is only called from another __init function. Mark
> detect_ivrs() __init to get rid of the warning.
>
> Fixes: b1e650db2cc4 ("iommu/amd: Add amd_iommu=force_enable
> option")
> Signed-off-by: Joerg Roedel
Acked-by: Alex Deucher
> ---
> drivers/iommu/amd/init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c index
> 4e4fb0f4e412..46280e6e1535 100644
> --- a/drivers/iommu/amd/init.c
> +++ b/drivers/iommu/amd/init.c
> @@ -2817,7 +2817,7 @@ static int amd_iommu_enable_interrupts(void)
> return ret;
> }
>
> -static bool detect_ivrs(void)
> +static bool __init detect_ivrs(void)
> {
> struct acpi_table_header *ivrs_base;
> acpi_status status;
> --
> 2.31.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
