[PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Will Deacon]

On Mon, Jan 29, 2018 at 04:16:33PM +0000, Shameerali Kolothum Thodi wrote:
> > -----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)
> > 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 -
> > next.
> > 
> > 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[1]. My expectation was that it will be
> through IOMMU. Anyway missed the boat now, I will re-spin for 4.17.

The problem with "ping" emails is that they don't really mean anything. In
this case, everybody probably assumed somebody else was picking it up so you
didn't get a reply.

Joerg may be ok pulling this, but it's odd to have dts changes going via his
tree. You might want to split those out, at least. Talk to him.

Will