From: Bjorn Helgaas <helgaas@kernel.org>
To: Zhangfei Gao <zhangfei.gao@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Joerg Roedel <joro@8bytes.org>,
Bjorn Helgaas <bhelgaas@google.com>,
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-kernel@vger.kernel.org>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-pci <linux-pci@vger.kernel.org>,
Thanu Rangarajan <Thanu.Rangarajan@arm.com>,
Souvik Chakravarty <Souvik.Chakravarty@arm.com>,
wanghuiqiang <wanghuiqiang@huawei.com>
Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
Date: Tue, 23 Jun 2020 10:04:27 -0500 [thread overview]
Message-ID: <20200623150427.GA2403606@bjorn-Precision-5520> (raw)
In-Reply-To: <c5d7b2f1-6b32-d965-3b60-eb70a26e02b4@linaro.org>
On Fri, Jun 19, 2020 at 10:26:54AM +0800, Zhangfei Gao wrote:
> Have studied _DSM method, two issues we met comparing using quirk.
>
> 1. Need change definition of either pci_host_bridge or pci_dev, like adding
> member can_stall,
> while pci system does not know stall now.
>
> a, pci devices do not have uuid: uuid need be described in dsdt, while pci
> devices are not defined in dsdt.
> so we have to use host bridge.
PCI devices *can* be described in the DSDT. IIUC these particular
devices are hardwired (not plug-in cards), so platform firmware can
know about them and could describe them in the DSDT.
> b, Parsing dsdt is in in pci subsystem.
> Like drivers/acpi/pci_root.c:
> obj = acpi_evaluate_dsm(ACPI_HANDLE(bus->bridge), &pci_acpi_dsm_guid,
> 1,
> IGNORE_PCI_BOOT_CONFIG_DSM, NULL);
>
> After parsing DSM in pci, we need record this info.
> Currently, can_stall info is recorded in iommu_fwspec,
> which is allocated in iommu_fwspec_init and called by iort_iommu_configure
> for uefi.
You can look for a _DSM wherever it is convenient for you. It could
be in an AMBA shim layer.
> 2. Guest kernel also need support sva.
> Using quirk, the guest can boot with sva enabled, since quirk is
> self-contained by kernel.
> If using _DSM, a specific uefi or dtb has to be provided,
> currently we can useQEMU_EFI.fd from apt install qemu-efi
I don't quite understand what this means, but as I mentioned before, a
quirk for a *limited* number of devices is OK, as long as there is a
plan that removes the need for a quirk for future devices.
E.g., if the next platform version ships with a DTB or firmware with a
_DSM or other mechanism that enables the kernel to discover this
information without a kernel change, it's fine to use a quirk to cover
the early platform.
The principles are:
- I don't want to have to update a quirk for every new Device ID
that needs this.
- I don't really want to have to manage non-PCI information in the
struct pci_dev. If this is AMBA- or IOMMU-related, it should be
stored in a structure related to AMBA or the IOMMU.
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Zhangfei Gao <zhangfei.gao@linaro.org>
Cc: linux-pci <linux-pci@vger.kernel.org>,
Hanjun Guo <guohanjun@huawei.com>,
jean-philippe <jean-philippe@linaro.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Len Brown <lenb@kernel.org>,
Thanu Rangarajan <Thanu.Rangarajan@arm.com>,
Souvik Chakravarty <Souvik.Chakravarty@arm.com>,
Arnd Bergmann <arnd@arndb.de>,
Bjorn Helgaas <bhelgaas@google.com>,
wanghuiqiang <wanghuiqiang@huawei.com>,
kenneth-lee-2012@foxmail.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"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>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
Date: Tue, 23 Jun 2020 10:04:27 -0500 [thread overview]
Message-ID: <20200623150427.GA2403606@bjorn-Precision-5520> (raw)
In-Reply-To: <c5d7b2f1-6b32-d965-3b60-eb70a26e02b4@linaro.org>
On Fri, Jun 19, 2020 at 10:26:54AM +0800, Zhangfei Gao wrote:
> Have studied _DSM method, two issues we met comparing using quirk.
>
> 1. Need change definition of either pci_host_bridge or pci_dev, like adding
> member can_stall,
> while pci system does not know stall now.
>
> a, pci devices do not have uuid: uuid need be described in dsdt, while pci
> devices are not defined in dsdt.
> so we have to use host bridge.
PCI devices *can* be described in the DSDT. IIUC these particular
devices are hardwired (not plug-in cards), so platform firmware can
know about them and could describe them in the DSDT.
> b, Parsing dsdt is in in pci subsystem.
> Like drivers/acpi/pci_root.c:
> obj = acpi_evaluate_dsm(ACPI_HANDLE(bus->bridge), &pci_acpi_dsm_guid,
> 1,
> IGNORE_PCI_BOOT_CONFIG_DSM, NULL);
>
> After parsing DSM in pci, we need record this info.
> Currently, can_stall info is recorded in iommu_fwspec,
> which is allocated in iommu_fwspec_init and called by iort_iommu_configure
> for uefi.
You can look for a _DSM wherever it is convenient for you. It could
be in an AMBA shim layer.
> 2. Guest kernel also need support sva.
> Using quirk, the guest can boot with sva enabled, since quirk is
> self-contained by kernel.
> If using _DSM, a specific uefi or dtb has to be provided,
> currently we can useQEMU_EFI.fd from apt install qemu-efi
I don't quite understand what this means, but as I mentioned before, a
quirk for a *limited* number of devices is OK, as long as there is a
plan that removes the need for a quirk for future devices.
E.g., if the next platform version ships with a DTB or firmware with a
_DSM or other mechanism that enables the kernel to discover this
information without a kernel change, it's fine to use a quirk to cover
the early platform.
The principles are:
- I don't want to have to update a quirk for every new Device ID
that needs this.
- I don't really want to have to manage non-PCI information in the
struct pci_dev. If this is AMBA- or IOMMU-related, it should be
stored in a structure related to AMBA or the IOMMU.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Zhangfei Gao <zhangfei.gao@linaro.org>
Cc: linux-pci <linux-pci@vger.kernel.org>,
Hanjun Guo <guohanjun@huawei.com>,
jean-philippe <jean-philippe@linaro.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Joerg Roedel <joro@8bytes.org>,
Wangzhou <wangzhou1@hisilicon.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Len Brown <lenb@kernel.org>,
Thanu Rangarajan <Thanu.Rangarajan@arm.com>,
Souvik Chakravarty <Souvik.Chakravarty@arm.com>,
Arnd Bergmann <arnd@arndb.de>,
Bjorn Helgaas <bhelgaas@google.com>,
wanghuiqiang <wanghuiqiang@huawei.com>,
kenneth-lee-2012@foxmail.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"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>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@vger.kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
Date: Tue, 23 Jun 2020 10:04:27 -0500 [thread overview]
Message-ID: <20200623150427.GA2403606@bjorn-Precision-5520> (raw)
In-Reply-To: <c5d7b2f1-6b32-d965-3b60-eb70a26e02b4@linaro.org>
On Fri, Jun 19, 2020 at 10:26:54AM +0800, Zhangfei Gao wrote:
> Have studied _DSM method, two issues we met comparing using quirk.
>
> 1. Need change definition of either pci_host_bridge or pci_dev, like adding
> member can_stall,
> while pci system does not know stall now.
>
> a, pci devices do not have uuid: uuid need be described in dsdt, while pci
> devices are not defined in dsdt.
> so we have to use host bridge.
PCI devices *can* be described in the DSDT. IIUC these particular
devices are hardwired (not plug-in cards), so platform firmware can
know about them and could describe them in the DSDT.
> b, Parsing dsdt is in in pci subsystem.
> Like drivers/acpi/pci_root.c:
> obj = acpi_evaluate_dsm(ACPI_HANDLE(bus->bridge), &pci_acpi_dsm_guid,
> 1,
> IGNORE_PCI_BOOT_CONFIG_DSM, NULL);
>
> After parsing DSM in pci, we need record this info.
> Currently, can_stall info is recorded in iommu_fwspec,
> which is allocated in iommu_fwspec_init and called by iort_iommu_configure
> for uefi.
You can look for a _DSM wherever it is convenient for you. It could
be in an AMBA shim layer.
> 2. Guest kernel also need support sva.
> Using quirk, the guest can boot with sva enabled, since quirk is
> self-contained by kernel.
> If using _DSM, a specific uefi or dtb has to be provided,
> currently we can useQEMU_EFI.fd from apt install qemu-efi
I don't quite understand what this means, but as I mentioned before, a
quirk for a *limited* number of devices is OK, as long as there is a
plan that removes the need for a quirk for future devices.
E.g., if the next platform version ships with a DTB or firmware with a
_DSM or other mechanism that enables the kernel to discover this
information without a kernel change, it's fine to use a quirk to cover
the early platform.
The principles are:
- I don't want to have to update a quirk for every new Device ID
that needs this.
- I don't really want to have to manage non-PCI information in the
struct pci_dev. If this is AMBA- or IOMMU-related, it should be
stored in a structure related to AMBA or the IOMMU.
_______________________________________________
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-06-23 15:04 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
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 [this message]
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=20200623150427.GA2403606@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--cc=Souvik.Chakravarty@arm.com \
--cc=Thanu.Rangarajan@arm.com \
--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=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=wanghuiqiang@huawei.com \
--cc=wangzhou1@hisilicon.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 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.