Re: [PATCH v2] PCI: Add DMA alias for Intel Corporation 8 Series HECI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[+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



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux