From: Bjorn Helgaas <helgaas@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: jean-philippe <jean-philippe@linaro.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
linux-pci <linux-pci@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Hanjun Guo <guohanjun@huawei.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
kenneth-lee-2012@foxmail.com,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Zhangfei Gao <zhangfei.gao@linaro.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
Date: Tue, 9 Jun 2020 11:49:26 -0500 [thread overview]
Message-ID: <20200609164926.GA1452092@bjorn-Precision-5520> (raw)
In-Reply-To: <CAK8P3a38bhE_VO_eVcsfsGKgED=gmSEntQmrhwbLkeA6Si0qaw@mail.gmail.com>
On Tue, Jun 09, 2020 at 11:15:06AM +0200, Arnd Bergmann wrote:
> On Tue, Jun 9, 2020 at 6:02 AM Zhangfei Gao <zhangfei.gao@linaro.org> wrote:
> > On 2020/6/9 上午12:41, Bjorn Helgaas wrote:
> > > On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote:
> > >> On 2020/6/6 上午7:19, Bjorn Helgaas wrote:
> > >>>> +++ b/drivers/iommu/iommu.c
> > >>>> @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct
> > >>>> fwnode_handle *iommu_fwnode,
> > >>>> fwspec->iommu_fwnode = iommu_fwnode;
> > >>>> fwspec->ops = ops;
> > >>>> dev_iommu_fwspec_set(dev, fwspec);
> > >>>> +
> > >>>> + if (dev_is_pci(dev))
> > >>>> + pci_fixup_device(pci_fixup_final, to_pci_dev(dev));
> > >>>> +
> > >>>>
> > >>>> Then pci_fixup_final will be called twice, the first in pci_bus_add_device.
> > >>>> Here in iommu_fwspec_init is the second time, specifically for iommu_fwspec.
> > >>>> Will send this when 5.8-rc1 is open.
> > >>> Wait, this whole fixup approach seems wrong to me. No matter how you
> > >>> do the fixup, it's still a fixup, which means it requires ongoing
> > >>> maintenance. Surely we don't want to have to add the Vendor/Device ID
> > >>> for every new AMBA device that comes along, do we?
> > >>>
> > >> Here the fake pci device has standard PCI cfg space, but physical
> > >> implementation is base on AMBA
> > >> They can provide pasid feature.
> > >> However,
> > >> 1, does not support tlp since they are not real pci devices.
> > >> 2. does not support pri, instead support stall (provided by smmu)
> > >> And stall is not a pci feature, so it is not described in struct pci_dev,
> > >> but in struct iommu_fwspec.
> > >> So we use this fixup to tell pci system that the devices can support stall,
> > >> and hereby support pasid.
> > > This did not answer my question. Are you proposing that we update a
> > > quirk every time a new AMBA device is released? I don't think that
> > > would be a good model.
> >
> > Yes, you are right, but we do not have any better idea yet.
> > Currently we have three fake pci devices, which support stall and pasid.
> > We have to let pci system know the device can support pasid, because of
> > stall feature, though not support pri.
> > Do you have any other ideas?
>
> It sounds like the best way would be to allocate a PCI capability for it, so
> detection can be done through config space, at least in future devices,
> or possibly after a firmware update if the config space in your system
> is controlled by firmware somewhere. Once there is a proper mechanism
> to do this, using fixups to detect the early devices that don't use that
> should be uncontroversial. I have no idea what the process or timeline
> is to add new capabilities into the PCIe specification, or if this one
> would be acceptable to the PCI SIG at all.
That sounds like a possibility. The spec already defines a
Vendor-Specific Extended Capability (PCIe r5.0, sec 7.9.5) that might
be a candidate.
> If detection cannot be done through PCI config space, the next best
> alternative is to pass auxiliary data through firmware. On DT based
> machines, you can list non-hotpluggable PCIe devices and add custom
> properties that could be read during device enumeration. I assume
> ACPI has something similar, but I have not done that.
ACPI has _DSM (ACPI v6.3, sec 9.1.1), which might be a candidate. I
like this better than a PCI capability because the property you need
to expose is not a PCI property.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-06-09 16:49 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-26 11:49 [PATCH 0/2] Introduce PCI_FIXUP_IOMMU Zhangfei Gao
2020-05-26 11:49 ` [PATCH 1/2] PCI: " Zhangfei Gao
2020-05-26 14:46 ` Christoph Hellwig
2020-05-26 15:09 ` Zhangfei Gao
2020-05-27 9:01 ` Greg Kroah-Hartman
2020-05-26 11:49 ` [PATCH 2/2] iommu: calling pci_fixup_iommu in iommu_fwspec_init Zhangfei Gao
2020-05-27 9:01 ` Greg Kroah-Hartman
2020-05-28 6:53 ` Zhangfei Gao
2020-05-27 9:00 ` [PATCH 0/2] Introduce PCI_FIXUP_IOMMU Greg Kroah-Hartman
2020-05-27 9:53 ` Arnd Bergmann
2020-05-27 13:51 ` Zhangfei Gao
2020-05-27 18:18 ` Bjorn Helgaas
2020-05-28 6:46 ` Zhangfei Gao
2020-05-28 7:33 ` Joerg Roedel
2020-06-01 17:41 ` Bjorn Helgaas
2020-06-04 13:33 ` Zhangfei Gao
2020-06-05 23:19 ` Bjorn Helgaas
2020-06-08 2:54 ` Zhangfei Gao
2020-06-08 16:41 ` Bjorn Helgaas
2020-06-09 4:01 ` Zhangfei Gao
2020-06-09 9:15 ` Arnd Bergmann
2020-06-09 16:49 ` Bjorn Helgaas [this message]
2020-06-11 2:54 ` Zhangfei Gao
2020-06-11 13:44 ` Bjorn Helgaas
2020-06-13 14:30 ` Zhangfei Gao
2020-06-15 23:52 ` Bjorn Helgaas
2020-06-19 2:26 ` Zhangfei Gao
2020-06-23 15:04 ` Bjorn Helgaas
2020-12-16 11:24 ` Zhou Wang
2020-12-17 20:38 ` Bjorn Helgaas
2021-01-12 7:05 ` zhangfei.gao
2020-06-22 11:55 ` Joerg Roedel
2020-06-23 7:48 ` Zhangfei Gao
2020-06-22 11:53 ` Joerg Roedel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200609164926.GA1452092@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=guohanjun@huawei.com \
--cc=herbert@gondor.apana.org.au \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=kenneth-lee-2012@foxmail.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--cc=zhangfei.gao@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).