[+to Jarkko, Tomas, Alexander; can any of you confirm this behavior of the HECI device? Are there any other HECI devices that should be included in this quirk?] [+cc David, Lu, iommu list] On Mon, Nov 21, 2022 at 05:40:37PM +0100, Francisco Blas Izquierdo Riera wrote: > PCI: Add function 7 DMA alias quirk for Intel Corporation 8 Series HECI. > > Intel Corporation 8 Series HECIs include support for a CRB TPM 2.0 > device. When the device is enabled on the BIOS, the TPM 2.0 device is > detected but the IOMMU prevents it from being accessed. > > Even on a computer with a fixed DMAR table, device initialization > fails with DMA errors: > DMAR: DRHD: handling fault status reg 3 > DMAR: [DMA Read NO_PASID] Request device [00:16.7] fault addr 0xdceff000 [fault reason 0x06] PTE Read access is not set > DMAR: DRHD: handling fault status reg 2 > DMAR: [DMA Write NO_PASID] Request device [00:16.7] fault addr 0xdceff000 [fault reason 0x05] PTE Write access is not set > DMAR: DRHD: handling fault status reg 2 > DMAR: [DMA Write NO_PASID] Request device [00:16.7] fault addr 0xdceff000 [fault reason 0x05] PTE Write access is not set > tpm tpm0: Operation Timed out > DMAR: DRHD: handling fault status reg 3 > tpm tpm0: Operation Timed out > tpm_crb: probe of MSFT0101:00 failed with error -62 > > After patching the DMAR table and adding this patch, the TPM 2.0 > device is initialized correctly and no DMA errors appear. Accessing > the TPM 2.0 PCR banks also works as expected. Francisco, is the DMAR patch *also* required? We have several similar quirks for devices that use unexpected function numbers, but I don't remember any that require DMAR changes. A kernel quirk requires no action on the part of users, so that's easy. But I don't think it's practical for ordinary users to extract the DMAR, disassemble it, patch it, recompile it, and update the initramfs as described in your blog post. Is there a way to add a kernel quirk to accomplish the same DMAR override? > Since most Haswell computers supporting this do not seem to have a > valid DMAR table patching the table with an appropriate RMRR is > usually also needed. I have published a blogpost describing the > process. > > This patch currently adds the alias only for function 0. Since this > is the only function I have seen provided by the HECI on actual > hardware. > > > V2: Resent using a sendmail to fix tab mangling made by Thunderbird. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=108251 > Link: https://klondike.es/klog/2022/11/21/patching-the-acpi-dmar-table-to-allow-tpm2-0/ > Reported-by: Pierre Chifflier <chifflier@xxxxxxxxx> > Tested-by: Francisco Blas Izquierdo Riera (klondike) <klondike@xxxxxxxxxxx> > Signed-off-by: Francisco Blas Izquierdo Riera <klondike@xxxxxxxxxxx> > Suggested-by: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx> > Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > Cc: stable@xxxxxxxxxxxxxxx > > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -4162,6 +4162,22 @@ > 0x0122, /* Plextor M6E (Marvell 88SS9183)*/ > quirk_dma_func1_alias); > > +static void quirk_dma_func7_alias(struct pci_dev *dev) > +{ > + if (PCI_FUNC(dev->devfn) == 0) > + pci_add_dma_alias(dev, PCI_DEVFN(PCI_SLOT(dev->devfn), 7), 1); > +} > + > +/* > + * Certain HECIs in Haswell systems support TPM 2.0. Unfortunately they > + * perform DMA using the hidden function 7. Fixing this requires this > + * alias and a patch of the DMAR ACPI table to include the appropriate > + * MTRR. > + * https://bugzilla.kernel.org/show_bug.cgi?id=108251 > + */ > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x9c3a, > + quirk_dma_func7_alias); > + > /* > * Some devices DMA with the wrong devfn, not just the wrong function. > * quirk_fixed_dma_alias() uses this table to create fixed aliases, where
