From: Zhangfei Gao <zhangfei.gao@linaro.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Joerg Roedel <joro@8bytes.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Arnd Bergmann <arnd@arndb.de>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Hanjun Guo <guohanjun@huawei.com>,
Sudeep Holla <sudeep.holla@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>,
jean-philippe <jean-philippe@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
kenneth-lee-2012@foxmail.com, Wangzhou <wangzhou1@hisilicon.com>,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
iommu@lists.linux-foundation.org, linux-acpi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
Date: Thu, 28 May 2020 14:46:54 +0800 [thread overview]
Message-ID: <83bd3d72-3a0c-d9b6-54ad-5bc0dbc5be7d@linaro.org> (raw)
In-Reply-To: <20200527181842.GA256680@bjorn-Precision-5520>
Hi, Bjorn
On 2020/5/28 上午2:18, Bjorn Helgaas wrote:
> On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote:
>> Some platform devices appear as PCI but are actually on the AMBA bus,
>> and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
>> Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
>> is allocated, instead of reusing PCI_FIXUP_FINAL since it will slow
>> down iommu probing as all devices in fixup final list will be
>> reprocessed, suggested by Joerg, [1]
> Is this slowdown significant? We already iterate over every device
> when applying PCI_FIXUP_FINAL quirks, so if we used the existing
> PCI_FIXUP_FINAL, we wouldn't be adding a new loop. We would only be
> adding two more iterations to the loop in pci_do_fixups() that tries
> to match quirks against the current device. I doubt that would be a
> measurable slowdown.
I do not notice the difference when compared fixup_iommu and fixup_final
via get_jiffies_64,
since in our platform no other pci fixup is registered.
Here the plan is adding pci_fixup_device in iommu_fwspec_init,
so if using fixup_final the iteration will be done again here.
>
>> For example:
>> Hisilicon platform device need fixup in
>> drivers/pci/quirks.c handling fwspec->can_stall, which is introduced in [2]
>>
>> +static void quirk_huawei_pcie_sva(struct pci_dev *pdev)
>> +{
>> + struct iommu_fwspec *fwspec;
>> +
>> + pdev->eetlp_prefix_path = 1;
>> + fwspec = dev_iommu_fwspec_get(&pdev->dev);
>> + if (fwspec)
>> + fwspec->can_stall = 1;
>> +}
>> +
>> +DECLARE_PCI_FIXUP_IOMMU(PCI_VENDOR_ID_HUAWEI, 0xa250, quirk_huawei_pcie_sva);
>> +DECLARE_PCI_iFIXUP_IOMMU(PCI_VENDOR_ID_HUAWEI, 0xa251, quirk_huawei_pcie_sva);
>>
>> [1] https://www.spinics.net/lists/iommu/msg44591.html
>> [2] https://www.spinics.net/lists/linux-pci/msg94559.html
> If you reference these in the commit logs, please use lore.kernel.org
> links instead of spinics.
Got it, thanks Bjorn.
WARNING: multiple messages have this Message-ID (diff)
From: Zhangfei Gao <zhangfei.gao@linaro.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: jean-philippe <jean-philippe@linaro.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Arnd Bergmann <arnd@arndb.de>,
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, iommu@lists.linux-foundation.org,
linux-acpi@vger.kernel.org, linux-crypto@vger.kernel.org,
Sudeep Holla <sudeep.holla@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
kenneth-lee-2012@foxmail.com,
linux-arm-kernel@lists.infradead.org, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
Date: Thu, 28 May 2020 14:46:54 +0800 [thread overview]
Message-ID: <83bd3d72-3a0c-d9b6-54ad-5bc0dbc5be7d@linaro.org> (raw)
In-Reply-To: <20200527181842.GA256680@bjorn-Precision-5520>
Hi, Bjorn
On 2020/5/28 上午2:18, Bjorn Helgaas wrote:
> On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote:
>> Some platform devices appear as PCI but are actually on the AMBA bus,
>> and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
>> Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
>> is allocated, instead of reusing PCI_FIXUP_FINAL since it will slow
>> down iommu probing as all devices in fixup final list will be
>> reprocessed, suggested by Joerg, [1]
> Is this slowdown significant? We already iterate over every device
> when applying PCI_FIXUP_FINAL quirks, so if we used the existing
> PCI_FIXUP_FINAL, we wouldn't be adding a new loop. We would only be
> adding two more iterations to the loop in pci_do_fixups() that tries
> to match quirks against the current device. I doubt that would be a
> measurable slowdown.
I do not notice the difference when compared fixup_iommu and fixup_final
via get_jiffies_64,
since in our platform no other pci fixup is registered.
Here the plan is adding pci_fixup_device in iommu_fwspec_init,
so if using fixup_final the iteration will be done again here.
>
>> For example:
>> Hisilicon platform device need fixup in
>> drivers/pci/quirks.c handling fwspec->can_stall, which is introduced in [2]
>>
>> +static void quirk_huawei_pcie_sva(struct pci_dev *pdev)
>> +{
>> + struct iommu_fwspec *fwspec;
>> +
>> + pdev->eetlp_prefix_path = 1;
>> + fwspec = dev_iommu_fwspec_get(&pdev->dev);
>> + if (fwspec)
>> + fwspec->can_stall = 1;
>> +}
>> +
>> +DECLARE_PCI_FIXUP_IOMMU(PCI_VENDOR_ID_HUAWEI, 0xa250, quirk_huawei_pcie_sva);
>> +DECLARE_PCI_iFIXUP_IOMMU(PCI_VENDOR_ID_HUAWEI, 0xa251, quirk_huawei_pcie_sva);
>>
>> [1] https://www.spinics.net/lists/iommu/msg44591.html
>> [2] https://www.spinics.net/lists/linux-pci/msg94559.html
> If you reference these in the commit logs, please use lore.kernel.org
> links instead of spinics.
Got it, thanks Bjorn.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Zhangfei Gao <zhangfei.gao@linaro.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: jean-philippe <jean-philippe@linaro.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Arnd Bergmann <arnd@arndb.de>,
linux-pci@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joerg Roedel <joro@8bytes.org>, Hanjun Guo <guohanjun@huawei.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-acpi@vger.kernel.org, Wangzhou <wangzhou1@hisilicon.com>,
linux-crypto@vger.kernel.org, Sudeep Holla <sudeep.holla@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
kenneth-lee-2012@foxmail.com,
linux-arm-kernel@lists.infradead.org, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
Date: Thu, 28 May 2020 14:46:54 +0800 [thread overview]
Message-ID: <83bd3d72-3a0c-d9b6-54ad-5bc0dbc5be7d@linaro.org> (raw)
In-Reply-To: <20200527181842.GA256680@bjorn-Precision-5520>
Hi, Bjorn
On 2020/5/28 上午2:18, Bjorn Helgaas wrote:
> On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote:
>> Some platform devices appear as PCI but are actually on the AMBA bus,
>> and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
>> Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
>> is allocated, instead of reusing PCI_FIXUP_FINAL since it will slow
>> down iommu probing as all devices in fixup final list will be
>> reprocessed, suggested by Joerg, [1]
> Is this slowdown significant? We already iterate over every device
> when applying PCI_FIXUP_FINAL quirks, so if we used the existing
> PCI_FIXUP_FINAL, we wouldn't be adding a new loop. We would only be
> adding two more iterations to the loop in pci_do_fixups() that tries
> to match quirks against the current device. I doubt that would be a
> measurable slowdown.
I do not notice the difference when compared fixup_iommu and fixup_final
via get_jiffies_64,
since in our platform no other pci fixup is registered.
Here the plan is adding pci_fixup_device in iommu_fwspec_init,
so if using fixup_final the iteration will be done again here.
>
>> For example:
>> Hisilicon platform device need fixup in
>> drivers/pci/quirks.c handling fwspec->can_stall, which is introduced in [2]
>>
>> +static void quirk_huawei_pcie_sva(struct pci_dev *pdev)
>> +{
>> + struct iommu_fwspec *fwspec;
>> +
>> + pdev->eetlp_prefix_path = 1;
>> + fwspec = dev_iommu_fwspec_get(&pdev->dev);
>> + if (fwspec)
>> + fwspec->can_stall = 1;
>> +}
>> +
>> +DECLARE_PCI_FIXUP_IOMMU(PCI_VENDOR_ID_HUAWEI, 0xa250, quirk_huawei_pcie_sva);
>> +DECLARE_PCI_iFIXUP_IOMMU(PCI_VENDOR_ID_HUAWEI, 0xa251, quirk_huawei_pcie_sva);
>>
>> [1] https://www.spinics.net/lists/iommu/msg44591.html
>> [2] https://www.spinics.net/lists/linux-pci/msg94559.html
> If you reference these in the commit logs, please use lore.kernel.org
> links instead of spinics.
Got it, thanks Bjorn.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-28 6:47 UTC|newest]
Thread overview: 102+ 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 ` Zhangfei Gao
2020-05-26 11:49 ` Zhangfei Gao
2020-05-26 11:49 ` [PATCH 1/2] PCI: " Zhangfei Gao
2020-05-26 11:49 ` Zhangfei Gao
2020-05-26 11:49 ` Zhangfei Gao
2020-05-26 14:46 ` Christoph Hellwig
2020-05-26 14:46 ` Christoph Hellwig
2020-05-26 14:46 ` Christoph Hellwig
2020-05-26 15:09 ` Zhangfei Gao
2020-05-26 15:09 ` Zhangfei Gao
2020-05-26 15:09 ` Zhangfei Gao
2020-05-27 9:01 ` Greg Kroah-Hartman
2020-05-27 9:01 ` Greg Kroah-Hartman
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-26 11:49 ` Zhangfei Gao
2020-05-26 11:49 ` Zhangfei Gao
2020-05-27 9:01 ` Greg Kroah-Hartman
2020-05-27 9:01 ` Greg Kroah-Hartman
2020-05-27 9:01 ` Greg Kroah-Hartman
2020-05-28 6:53 ` Zhangfei Gao
2020-05-28 6:53 ` Zhangfei Gao
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:00 ` Greg Kroah-Hartman
2020-05-27 9:00 ` Greg Kroah-Hartman
2020-05-27 9:53 ` Arnd Bergmann
2020-05-27 9:53 ` Arnd Bergmann
2020-05-27 9:53 ` Arnd Bergmann
2020-05-27 13:51 ` Zhangfei Gao
2020-05-27 13:51 ` Zhangfei Gao
2020-05-27 13:51 ` Zhangfei Gao
2020-05-27 18:18 ` Bjorn Helgaas
2020-05-27 18:18 ` Bjorn Helgaas
2020-05-27 18:18 ` Bjorn Helgaas
2020-05-28 6:46 ` Zhangfei Gao [this message]
2020-05-28 6:46 ` Zhangfei Gao
2020-05-28 6:46 ` Zhangfei Gao
2020-05-28 7:33 ` Joerg Roedel
2020-05-28 7:33 ` Joerg Roedel
2020-05-28 7:33 ` Joerg Roedel
2020-06-01 17:41 ` Bjorn Helgaas
2020-06-01 17:41 ` Bjorn Helgaas
2020-06-01 17:41 ` Bjorn Helgaas
2020-06-04 13:33 ` Zhangfei Gao
2020-06-04 13:33 ` Zhangfei Gao
2020-06-04 13:33 ` Zhangfei Gao
2020-06-05 23:19 ` Bjorn Helgaas
2020-06-05 23:19 ` Bjorn Helgaas
2020-06-05 23:19 ` Bjorn Helgaas
2020-06-08 2:54 ` Zhangfei Gao
2020-06-08 2:54 ` Zhangfei Gao
2020-06-08 2:54 ` Zhangfei Gao
2020-06-08 16:41 ` Bjorn Helgaas
2020-06-08 16:41 ` Bjorn Helgaas
2020-06-08 16:41 ` Bjorn Helgaas
2020-06-09 4:01 ` Zhangfei Gao
2020-06-09 4:01 ` Zhangfei Gao
2020-06-09 4:01 ` Zhangfei Gao
2020-06-09 9:15 ` Arnd Bergmann
2020-06-09 9:15 ` Arnd Bergmann
2020-06-09 9:15 ` Arnd Bergmann
2020-06-09 16:49 ` Bjorn Helgaas
2020-06-09 16:49 ` Bjorn Helgaas
2020-06-09 16:49 ` Bjorn Helgaas
2020-06-11 2:54 ` Zhangfei Gao
2020-06-11 2:54 ` Zhangfei Gao
2020-06-11 2:54 ` Zhangfei Gao
2020-06-11 13:44 ` Bjorn Helgaas
2020-06-11 13:44 ` Bjorn Helgaas
2020-06-11 13:44 ` Bjorn Helgaas
2020-06-13 14:30 ` Zhangfei Gao
2020-06-13 14:30 ` Zhangfei Gao
2020-06-13 14:30 ` Zhangfei Gao
2020-06-15 23:52 ` Bjorn Helgaas
2020-06-15 23:52 ` Bjorn Helgaas
2020-06-15 23:52 ` Bjorn Helgaas
2020-06-19 2:26 ` Zhangfei Gao
2020-06-19 2:26 ` Zhangfei Gao
2020-06-19 2:26 ` Zhangfei Gao
2020-06-23 15:04 ` Bjorn Helgaas
2020-06-23 15:04 ` Bjorn Helgaas
2020-06-23 15:04 ` Bjorn Helgaas
2020-12-16 11:24 ` Zhou Wang
2020-12-16 11:24 ` Zhou Wang
2020-12-16 11:24 ` Zhou Wang
2020-12-17 20:38 ` Bjorn Helgaas
2020-12-17 20:38 ` Bjorn Helgaas
2020-12-17 20:38 ` Bjorn Helgaas
2021-01-12 6:49 ` [PATCH] PCI: Add a quirk to enable SVA for HiSilicon chip Zhangfei Gao
2021-01-12 17:02 ` Bjorn Helgaas
2021-01-13 12:05 ` Zhangfei Gao
2021-01-13 14:39 ` Jean-Philippe Brucker
2021-01-12 7:05 ` [PATCH 0/2] Introduce PCI_FIXUP_IOMMU zhangfei.gao
2021-01-12 7:05 ` zhangfei.gao
2020-06-22 11:55 ` Joerg Roedel
2020-06-22 11:55 ` Joerg Roedel
2020-06-23 7:48 ` Zhangfei Gao
2020-06-23 7:48 ` Zhangfei Gao
2020-06-22 11:53 ` Joerg Roedel
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=83bd3d72-3a0c-d9b6-54ad-5bc0dbc5be7d@linaro.org \
--to=zhangfei.gao@linaro.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=guohanjun@huawei.com \
--cc=helgaas@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.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=lorenzo.pieralisi@arm.com \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--cc=wangzhou1@hisilicon.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.