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

Shameerali Kolothum Thodi shameerali.kolothum.thodi at huawei.com
Wed Jan 31 01:30:47 PST 2018


Hi Joerg,

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Monday, January 29, 2018 4:42 PM
> To: 'Will Deacon' <will.deacon at arm.com>; Joerg Roedel <joro at 8bytes.org>
> 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 Joerg,
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon at arm.com]
> > Sent: Monday, January 29, 2018 4:21 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 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.
> >
> 
> This series has all the necessary ACKs from all concerned and as mentioned
> above somehow created a confusion regarding the pull request. My apologies.
> 
> Could you please take a look and send out a pull request, if it is ok.
> 

Not sure you got a chance to go through this and sorry for asking again.
Please let me know if you can pull this still or it's too late for now.

Thanks,
Shameer



More information about the linux-arm-kernel mailing list