[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220215134232.GA7592@willie-the-truck>
Date: Tue, 15 Feb 2022 13:42:32 +0000
From: Will Deacon <will@...nel.org>
To: Robin Murphy <robin.murphy@....com>
Cc: Yicong Yang <yangyicong@...wei.com>, mark.rutland@....com,
prime.zeng@...wei.com, alexander.shishkin@...ux.intel.com,
linux-pci@...r.kernel.org, linuxarm@...wei.com,
Yicong Yang <yangyicong@...ilicon.com>,
daniel.thompson@...aro.org, peterz@...radead.org, mingo@...hat.com,
helgaas@...nel.org, liuqi115@...wei.com, mike.leach@...aro.org,
suzuki.poulose@....com, coresight@...ts.linaro.org,
acme@...nel.org, zhangshaokun@...ilicon.com,
linux-arm-kernel@...ts.infradead.org, mathieu.poirier@...aro.org,
gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org, iommu@...ts.linux-foundation.org,
leo.yan@...aro.org
Subject: Re: [PATCH v3 8/8] iommu/arm-smmu-v3: Make default domain type of
HiSilicon PTT device to identity
On Tue, Feb 15, 2022 at 01:30:26PM +0000, Robin Murphy wrote:
> On 2022-02-15 13:00, Will Deacon wrote:
> > On Mon, Feb 14, 2022 at 08:55:20PM +0800, Yicong Yang wrote:
> > > On 2022/1/24 21:11, Yicong Yang wrote:
> > > > The DMA of HiSilicon PTT device can only work with identical
> > > > mapping. So add a quirk for the device to force the domain
> > > > passthrough.
> > > >
> > > > Signed-off-by: Yicong Yang <yangyicong@...ilicon.com>
> > > > ---
> > > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 16 ++++++++++++++++
> > > > 1 file changed, 16 insertions(+)
> > > >
> > > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > > > index 6dc6d8b6b368..6f67a2b1dd27 100644
> > > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > > > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > > > @@ -2838,6 +2838,21 @@ static int arm_smmu_dev_disable_feature(struct device *dev,
> > > > }
> > > > }
> > > > +#define IS_HISI_PTT_DEVICE(pdev) ((pdev)->vendor == PCI_VENDOR_ID_HUAWEI && \
> > > > + (pdev)->device == 0xa12e)
> > > > +
> > > > +static int arm_smmu_def_domain_type(struct device *dev)
> > > > +{
> > > > + if (dev_is_pci(dev)) {
> > > > + struct pci_dev *pdev = to_pci_dev(dev);
> > > > +
> > > > + if (IS_HISI_PTT_DEVICE(pdev))
> > > > + return IOMMU_DOMAIN_IDENTITY;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > static struct iommu_ops arm_smmu_ops = {
> > > > .capable = arm_smmu_capable,
> > > > .domain_alloc = arm_smmu_domain_alloc,
> > > > @@ -2863,6 +2878,7 @@ static struct iommu_ops arm_smmu_ops = {
> > > > .sva_unbind = arm_smmu_sva_unbind,
> > > > .sva_get_pasid = arm_smmu_sva_get_pasid,
> > > > .page_response = arm_smmu_page_response,
> > > > + .def_domain_type = arm_smmu_def_domain_type,
> > > > .pgsize_bitmap = -1UL, /* Restricted during device attach */
> > > > .owner = THIS_MODULE,
> > > > };
> > > >
> > >
> > > Is this quirk ok with the SMMU v3 driver? Just want to confirm that I'm on the
> > > right way to dealing with the issue of our device.
> >
> > I don't think the quirk should be in the SMMUv3 driver. Assumedly, you would
> > have the exact same problem if you stuck the PTT device behind a different
> > type of IOMMU, and so the quirk should be handled by a higher level of the
> > stack.
>
> Conceptually, yes, but I'm inclined to be pragmatic here. Default domain
> quirks could only move out as far as the other end of the call from
> iommu_get_def_domain_type() - it's not like we could rely on some flag in a
> driver which may not even be loaded yet, let alone matched to the device.
> And even then there's an equal and opposite argument for why the core code
> should have to maintain a list of platform-specific quirks rather than code
> specific to the relevant platforms. The fact is that a HiSilicon RCiEP is
> not going to end up behind anything other than a HiSilicon IOMMU, and if
> those ever stop being SMMUv3 *and* such a quirk still exists we can worry
> about it then.
Perhaps, but you know that by adding this hook it's only a matter of time
before we get random compatible string matches in there, so I'd rather keep
the flood gates closed as long as we can.
Given that this is a PCI device, why can't we have a PCI quirk for devices
which require an identity mapping and then handle that in the IOMMU core?
> Ugly as it is, this is the status quo. I don't recall anyone ever arguing
> that the equivalent quirks for Intel integrated graphics should be made
> generic ;)
I don't know anything about Intel integrated graphics. Have they solved this
problem in a better way, or could they equally make use of a generic quirk?
Will
Powered by blists - more mailing lists