RE: [PATCH v3] iommu/vt-d: Disable IOMMU by default on Lenovo ThinkPad P50s
"Tian, Kevin" <[email protected]> Mon, 27 Jul 2026 05:05:53 +0000
| Newsgroups | dev.linux.lists.iommu,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CO1PR11MB48350C58435D27F981DF83DF8CCC2@CO1PR11MB4835.namprd11.prod.outlook.com> |
> From: Oliver Lin <[email protected]> > Sent: Monday, July 27, 2026 12:49 PM > > On 27/07/2026 12:03, Tian, Kevin wrote: > > If it's confirmed to be a hardware issue, it should be (or will be) > documented > > as an VT-d erratum. Then a quirk could be added accordingly. > > > > If Lenovo confirms to be a firmware issue, then they should release a new > > firmware version to fix it. It doesn't justify a quirk in iommu driver. > > > > and it is not about a policy "whether this issue should be *treated* as...". > > It needs a root cause first. > > > Hi Kevin, > > I performed additional investigation on the DMA fault. > > With intel_iommu enabled: > > DMAR: [DMA Read NO_PASID] Request device [0000:00:12.4] fault addr > 0xb7fff000 [fault reason 0x02] Present bit in context entry is clear > > However, requester ID 0000:00:12.4 does not appear in PCI enumeration: > > - `lspci -nn -s 00:12.4` returns no output > - `lspci -xxxx -s 00:12.0` through `00:12.4` all return no device > - `/sys/bus/pci/devices/` contains no matching entry > > I also checked the firmware-provided ACPI DMAR table. It contains scopes > for 00:02.0 and 00:14.0, but no scope for 00:12.4. > > Could this requester ID correspond to an internal platform device, or > does this suggest a firmware/platform issue? > from a hidden device? no idea... You should report this issue to Lenovo first as only they know the detail of this platform.