| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <BL1PR12MB51447D05D90FC2B25A43F55AF7F79@BL1PR12MB5144.namprd12.prod.outlook.com>
Date: Fri, 22 Apr 2022 20:05:25 +0000
From: "Deucher, Alexander" <Alexander.Deucher@....com>
To: Robin Murphy <robin.murphy@....com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"corbet@....net" <corbet@....net>, "hpa@...or.com" <hpa@...or.com>,
"x86@...nel.org" <x86@...nel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"bp@...en8.de" <bp@...en8.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"joro@...tes.org" <joro@...tes.org>,
"Suthikulpanit, Suravee" <Suravee.Suthikulpanit@....com>,
"will@...nel.org" <will@...nel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"Hegde, Vasant" <Vasant.Hegde@....com>
Subject: RE: [PATCH v4] Documentation: x86: rework IOMMU documentation
[Public]
> -----Original Message-----
> From: Robin Murphy <robin.murphy@....com>
> Sent: Friday, April 22, 2022 3:41 PM
> To: Deucher, Alexander <Alexander.Deucher@....com>; linux-
> doc@...r.kernel.org; linux-kernel@...r.kernel.org; corbet@....net;
> hpa@...or.com; x86@...nel.org; dave.hansen@...ux.intel.com;
> bp@...en8.de; mingo@...hat.com; tglx@...utronix.de; joro@...tes.org;
> Suthikulpanit, Suravee <Suravee.Suthikulpanit@....com>; will@...nel.org;
> iommu@...ts.linux-foundation.org; Hegde, Vasant <Vasant.Hegde@....com>
> 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, (0xfee00000 - 0xfeefffff).
> > +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 0x00000001 MSFT
> 0x00000097) @
> > +0x000000007f5b5ef0
> > +
> > +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: 0x00000000)base: 0x00000000fed90000
> > + ACPI DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed91000
> > + ACPI DMAR:DRHD (flags: 0x00000001)base: 0x00000000fed93000
> > + ACPI DMAR:RMRR base: 0x00000000000ed000 end:
> 0x00000000000effff
> > + ACPI DMAR:RMRR base: 0x000000007f600000 end:
> 0x000000007fffffff
> > +
> > +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=0xffffc02000 flags=0x0000]
> > + AMD-Vi: Event logged [IO_PAGE_FAULT device=07:00.0
> domain=0x0007
> > +address=0xffffc02000 flags=0x0000]
Powered by blists - more mailing lists