From: Eric Auger <eauger@redhat.com>
To: Joao Martins <joao.m.martins@oracle.com>, qemu-devel@nongnu.org
Cc: Alex Williamson <alex.williamson@redhat.com>,
Cedric Le Goater <clg@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, Peter Xu <peterx@redhat.com>,
David Hildenbrand <david@redhat.com>,
Philippe Mathieu-Daude <philmd@linaro.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Jason Wang <jasowang@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
Eduardo Habkost <eduardo@habkost.net>,
Avihai Horon <avihaih@nvidia.com>,
Jason Gunthorpe <jgg@nvidia.com>, Yi Liu <yi.l.liu@intel.com>
Subject: Re: [PATCH v4 01/15] hw/pci: Add a pci_setup_iommu_ops() helper
Date: Fri, 6 Oct 2023 10:45:57 +0200 [thread overview]
Message-ID: <439d42e6-0627-43d1-1a45-dbc92ef83380@redhat.com> (raw)
In-Reply-To: <20230622214845.3980-2-joao.m.martins@oracle.com>
Hi Joao,
On 6/22/23 23:48, Joao Martins wrote:
> From: Yi Liu <yi.l.liu@intel.com>
>
> Add a pci_setup_iommu_ops() that uses a newly added structure
> (PCIIOMMUOps) instead of using PCIIOMMUFunc. The old pci_setup_iommu()
> that uses PCIIOMMUFunc is still kept for other IOMMUs to get an
> an address space for a PCI device in vendor specific way.
double 'an'
>
> In preparation to expand to supplying vIOMMU attributes, add a
> alternate helper pci_setup_iommu_ops() to setup the PCI device IOMMU.
> For now the PCIIOMMUOps just defines the address_space, but it will
> be extended to have another callback.
>
> Signed-off-by: Yi Liu <yi.l.liu@intel.com>
> [joao: Massage commit message and subject, and make it a complementary
> rather than changing every single consumer of pci_setup_iommu()]
> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
> ---
> v1: https://lore.kernel.org/all/20210302203827.437645-5-yi.l.liu@intel.com/
> ---
> include/hw/pci/pci.h | 7 +++++++
> include/hw/pci/pci_bus.h | 1 +
> hw/pci/pci.c | 26 +++++++++++++++++++++++---
> 3 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> index e6d0574a2999..f59aef5a329a 100644
> --- a/include/hw/pci/pci.h
> +++ b/include/hw/pci/pci.h
> @@ -368,6 +368,13 @@ typedef AddressSpace *(*PCIIOMMUFunc)(PCIBus *, void *, int);
> AddressSpace *pci_device_iommu_address_space(PCIDevice *dev);
> void pci_setup_iommu(PCIBus *bus, PCIIOMMUFunc fn, void *opaque);
>
> +typedef struct PCIIOMMUOps PCIIOMMUOps;
> +struct PCIIOMMUOps {
> + AddressSpace * (*get_address_space)(PCIBus *bus,
> + void *opaque, int32_t devfn);
> +};
> +void pci_setup_iommu_ops(PCIBus *bus, const PCIIOMMUOps *iommu_ops, void *opaque);
> +
> pcibus_t pci_bar_address(PCIDevice *d,
> int reg, uint8_t type, pcibus_t size);
>
> diff --git a/include/hw/pci/pci_bus.h b/include/hw/pci/pci_bus.h
> index 56531759578f..fb770b236d69 100644
> --- a/include/hw/pci/pci_bus.h
> +++ b/include/hw/pci/pci_bus.h
> @@ -35,6 +35,7 @@ struct PCIBus {
> enum PCIBusFlags flags;
> PCIIOMMUFunc iommu_fn;
> void *iommu_opaque;
> + const PCIIOMMUOps *iommu_ops;
> uint8_t devfn_min;
> uint32_t slot_reserved_mask;
> pci_set_irq_fn set_irq;
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index bf38905b7dc0..4e32c09e81d6 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -2639,7 +2639,15 @@ AddressSpace *pci_device_iommu_address_space(PCIDevice *dev)
> PCIBus *iommu_bus = bus;
> uint8_t devfn = dev->devfn;
>
> - while (iommu_bus && !iommu_bus->iommu_fn && iommu_bus->parent_dev) {
> + /*
> + * get_address_space() callback is mandatory when iommu uses
> + * pci_setup_iommu_ops(), so needs to ensure its presence in
> + * the iommu_bus search.
the fact that it is mandatory should also be documented along with the
PCIIOMMUOps struct definition and enforced at pci_setup_iommu_ops()
removing the need for checking iommu_bus->iommu_ops->get_address_space
> + */
> + while (iommu_bus &&
> + !(iommu_bus->iommu_fn ||
> + (iommu_bus->iommu_ops && iommu_bus->iommu_ops->get_address_space)) &&
> + iommu_bus->parent_dev) {
> PCIBus *parent_bus = pci_get_bus(iommu_bus->parent_dev);
>
> /*
> @@ -2678,8 +2686,14 @@ AddressSpace *pci_device_iommu_address_space(PCIDevice *dev)
>
> iommu_bus = parent_bus;
> }
> - if (!pci_bus_bypass_iommu(bus) && iommu_bus && iommu_bus->iommu_fn) {
> - return iommu_bus->iommu_fn(bus, iommu_bus->iommu_opaque, devfn);
> + if (!pci_bus_bypass_iommu(bus) && iommu_bus) {
> + if (iommu_bus->iommu_fn) {
> + return iommu_bus->iommu_fn(bus, iommu_bus->iommu_opaque, devfn);
> + } else if (iommu_bus->iommu_ops &&
> + iommu_bus->iommu_ops->get_address_space) {
> + return iommu_bus->iommu_ops->get_address_space(bus,
> + iommu_bus->iommu_opaque, devfn);
> + }
> }
> return &address_space_memory;
> }
> @@ -2690,6 +2704,12 @@ void pci_setup_iommu(PCIBus *bus, PCIIOMMUFunc fn, void *opaque)
> bus->iommu_opaque = opaque;
> }
>
> +void pci_setup_iommu_ops(PCIBus *bus, const PCIIOMMUOps *ops, void *opaque)
> +{
> + bus->iommu_ops = ops;
> + bus->iommu_opaque = opaque;
maybe assert if both iommu_fn and iommu_ops are set to make sure the
conversion is not done partially? If I understand it correctly either of
those 2 ops should be set and not both.
> +}
> +
> static void pci_dev_get_w64(PCIBus *b, PCIDevice *dev, void *opaque)
> {
> Range *range = opaque;
Thanks
Eric
next prev parent reply other threads:[~2023-10-06 8:46 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 21:48 [PATCH v4 00/15] vfio: VFIO migration support with vIOMMU Joao Martins
2023-06-22 21:48 ` [PATCH v4 01/15] hw/pci: Add a pci_setup_iommu_ops() helper Joao Martins
2023-10-02 15:12 ` Cédric Le Goater
2023-10-06 8:38 ` Joao Martins
2023-10-06 8:50 ` Cédric Le Goater
2023-10-06 11:06 ` Joao Martins
2023-10-06 17:09 ` Cédric Le Goater
2023-10-06 17:59 ` Joao Martins
2023-10-09 13:01 ` Cédric Le Goater
2023-10-06 8:45 ` Eric Auger [this message]
2023-10-06 11:03 ` Joao Martins
2023-06-22 21:48 ` [PATCH v4 02/15] hw/pci: Refactor pci_device_iommu_address_space() Joao Martins
2023-10-02 15:22 ` Cédric Le Goater
2023-10-06 8:39 ` Joao Martins
2023-10-06 8:40 ` Joao Martins
2023-10-06 8:52 ` Eric Auger
2023-10-06 11:07 ` Joao Martins
2023-10-06 9:11 ` Eric Auger
2023-06-22 21:48 ` [PATCH v4 03/15] hw/pci: Introduce pci_device_iommu_get_attr() Joao Martins
2023-06-22 21:48 ` [PATCH v4 04/15] intel-iommu: Switch to pci_setup_iommu_ops() Joao Martins
2023-06-22 21:48 ` [PATCH v4 05/15] memory/iommu: Add IOMMU_ATTR_DMA_TRANSLATION attribute Joao Martins
2023-10-06 13:08 ` Eric Auger
2023-06-22 21:48 ` [PATCH v4 06/15] intel-iommu: Implement get_attr() method Joao Martins
2023-09-08 6:23 ` Duan, Zhenzhong
2023-09-08 10:11 ` Joao Martins
2023-10-02 15:23 ` Cédric Le Goater
2023-10-06 8:42 ` Joao Martins
2023-06-22 21:48 ` [PATCH v4 07/15] vfio/common: Track whether DMA Translation is enabled on the vIOMMU Joao Martins
2023-07-09 15:10 ` Avihai Horon
2023-07-10 13:44 ` Joao Martins
2023-10-06 13:09 ` Eric Auger
2023-06-22 21:48 ` [PATCH v4 08/15] vfio/common: Relax vIOMMU detection when DMA translation is off Joao Martins
2023-06-22 21:48 ` [PATCH v4 09/15] memory/iommu: Add IOMMU_ATTR_MAX_IOVA attribute Joao Martins
2023-06-22 21:48 ` [PATCH v4 10/15] intel-iommu: Implement IOMMU_ATTR_MAX_IOVA get_attr() attribute Joao Martins
2023-07-09 15:17 ` Avihai Horon
2023-07-10 13:44 ` Joao Martins
2023-10-02 15:42 ` Cédric Le Goater
2023-10-06 8:43 ` Joao Martins
2023-06-22 21:48 ` [PATCH v4 11/15] vfio/common: Move dirty tracking ranges update to helper Joao Martins
2023-06-22 21:48 ` [PATCH v4 12/15] vfio/common: Support device dirty page tracking with vIOMMU Joao Martins
2023-07-09 15:24 ` Avihai Horon
2023-07-10 13:49 ` Joao Martins
2023-09-08 6:11 ` Duan, Zhenzhong
2023-09-08 10:11 ` Joao Martins
2023-09-08 11:52 ` Duan, Zhenzhong
2023-09-08 11:54 ` Joao Martins
2023-06-22 21:48 ` [PATCH v4 13/15] vfio/common: Extract vIOMMU code from vfio_sync_dirty_bitmap() Joao Martins
2023-06-22 21:48 ` [PATCH v4 14/15] vfio/common: Optimize device dirty page tracking with vIOMMU Joao Martins
2023-06-22 21:48 ` [PATCH v4 15/15] vfio/common: Block migration with vIOMMUs without address width limits Joao Martins
2023-09-08 6:28 ` Duan, Zhenzhong
2023-09-08 10:11 ` Joao Martins
2023-06-22 22:18 ` [PATCH v4 00/15] vfio: VFIO migration support with vIOMMU Joao Martins
2023-09-07 11:11 ` Joao Martins
2023-09-07 12:40 ` Cédric Le Goater
2023-09-07 15:20 ` Joao Martins
2024-06-06 15:43 ` Cédric Le Goater
2024-06-07 15:10 ` Joao Martins
2024-06-10 16:53 ` Cédric Le Goater
2024-06-18 11:26 ` Joao Martins
2024-06-20 12:31 ` Cédric Le Goater
2024-11-28 3:19 ` Zhangfei Gao
2024-11-28 18:29 ` Joao Martins
2025-01-21 16:42 ` Joao Martins
2025-01-07 6:55 ` Zhangfei Gao
2025-01-21 16:42 ` Joao Martins
2025-02-08 2:07 ` Zhangfei Gao
2025-03-05 11:59 ` Joao Martins
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=439d42e6-0627-43d1-1a45-dbc92ef83380@redhat.com \
--to=eauger@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=avihaih@nvidia.com \
--cc=clg@redhat.com \
--cc=david@redhat.com \
--cc=eduardo@habkost.net \
--cc=jasowang@redhat.com \
--cc=jgg@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=yi.l.liu@intel.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.