[PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)
Shameerali Kolothum Thodi
shameerali.kolothum.thodi at huawei.com
Mon Jan 29 08:16:33 PST 2018
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Monday, January 29, 2018 3:40 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>
> Cc: lorenzo.pieralisi at arm.com; robin.murphy at arm.com;
> marc.zyngier at arm.com; joro at 8bytes.org; John Garry
> <john.garry at huawei.com>; xuwei (O) <xuwei5 at huawei.com>; Guohanjun
> (Hanjun Guo) <guohanjun at huawei.com>; iommu at lists.linux-foundation.org;
> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org;
> devicetree at vger.kernel.org; Linuxarm <linuxarm at huawei.com>
> Subject: Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> Hi Shameer,
> On Thu, Dec 14, 2017 at 04:09:54PM +0000, Shameer Kolothum wrote:
> > On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> > deviates from the standard implementation and this breaks PCIe MSI
> > functionality when SMMU is enabled.
> > The HiSilicon erratum 161010801 describes this limitation of certain
> > HiSilicon platforms to support the SMMU mappings for MSI transactions.
> > On these platforms GICv3 ITS translator is presented with the deviceID
> > by extending the MSI payload data to 64 bits to include the deviceID.
> > Hence, the PCIe controller on this platforms has to differentiate the
> > MSI payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI.
> > This patch implements an ACPI based quirk to reserve the hw msi
> > regions in the smmu-v3 driver which means these address regions will
> > not be translated and will be excluded from iova allocations.
> > To implement this quirk, the following changes are incorporated:
> > 1. Added a generic helper function to IORT code to retrieve and reserve
> > the associated ITS base address from a device IORT node. The function
> > has a check for smmu model to determine whether the platform requires
> > the HW MSI reservation or not.
> > 2. Added smmu node entries and explicitly disabled them in hip06/hip07
> > dts files so that users are warned about the non-DT support for this
> > erratum.
> > arch/arm64/boot/dts/hisilicon/hip06.dtsi | 56 ++++++++++++++++
> > arch/arm64/boot/dts/hisilicon/hip07.dtsi | 25 +++++++
> > drivers/acpi/arm64/iort.c | 111
> > drivers/iommu/dma-iommu.c | 8 ++-
> > drivers/irqchip/irq-gic-v3-its.c | 3 +-
> > include/linux/acpi_iort.h | 7 +-
> > 6 files changed, 204 insertions(+), 6 deletions(-)
> It occurred to me this morning that this series probably isn't queued anywhere
> because it's not obvious which tree is supposed to take it and I can't see it in -
> Is this one for arm64, IOMMU, irqchip or something else? It's probably missed
> the boat for 4.16 now...
I have been trying to ping you guys on this. My expectation was that it will be
through IOMMU. Anyway missed the boat now, I will re-spin for 4.17.
More information about the linux-arm-kernel