[+cc Jarkko, tpm_crb author] 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. > > 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 Given that significant additional effort to override the DMAR table is required before this quirk is useful, I'm deferring this quirk for now. People willing to recompile the DMAR will probably also be able to apply the quirk and rebuild the kernel. Does the TPM work under Windows? If so, it would suggest that there's a different way to use it that doesn't require the quirk or the DMAR override. Or maybe it only works on Windows without the IOMMU being enabled? Naive question: apparently the TPM is doing DMA reads/writes. I see tpm_crb.c doing MMIO mappings (ioremap()), but I don't see any DMA mappings. Is that implicit or done elsewhere? Bjorn > --- 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
