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

[Shameerali Kolothum Thodi]

Hi Will,

> -----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 -
> 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.

Thanks,
Shameer
1. https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg21391.html