From: "Michael S. Tsirkin" <mst@redhat.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
qemu-devel@nongnu.org,
"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>,
"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>
Subject: Re: [PATCH v3 01/15] hw/pci: Refactor pci_device_iommu_address_space()
Date: Thu, 22 Jun 2023 16:50:28 -0400 [thread overview]
Message-ID: <20230622165003-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <41a452d7-5b17-d2b8-401e-5b5e7ddb5299@oracle.com>
On Wed, May 31, 2023 at 11:03:23AM +0100, Joao Martins wrote:
> On 30/05/2023 23:04, Philippe Mathieu-Daudé wrote:
> > Hi Joao,
> >
> > On 30/5/23 19:59, Joao Martins wrote:
> >> Rename pci_device_iommu_address_space() into pci_device_iommu_info().
> >> In the new function return a new type PCIAddressSpace that encapsulates
> >> the AddressSpace pointer that originally was returned.
> >>
> >> The new type is added in preparation to expanding it to include the IOMMU
> >> memory region as a new field, such that we are able to fetch attributes of
> >> the vIOMMU e.g. at vfio migration setup.
> >>
> >> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
> >> ---
> >> hw/pci/pci.c | 9 ++++++---
> >> include/hw/pci/pci.h | 21 ++++++++++++++++++++-
> >
> > Please consider using scripts/git.orderfile.
> >
> Will do -- wasn't aware of that script.
>
> >> 2 files changed, 26 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> >> index 1cc7c89036b5..ecf8a543aa77 100644
> >> --- a/hw/pci/pci.c
> >> +++ b/hw/pci/pci.c
> >> @@ -2633,11 +2633,12 @@ static void pci_device_class_base_init(ObjectClass
> >> *klass, void *data)
> >> }
> >> }
> >> -AddressSpace *pci_device_iommu_address_space(PCIDevice *dev)
> >> +PCIAddressSpace pci_device_iommu_info(PCIDevice *dev)
> >> {
> >
> > This function is PCI specific, ...
> >
> >> }
> >> void pci_setup_iommu(PCIBus *bus, PCIIOMMUFunc fn, void *opaque)
> >> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> >> index e6d0574a2999..9ffaf47fe2ab 100644
> >> --- a/include/hw/pci/pci.h
> >> +++ b/include/hw/pci/pci.h
> >> @@ -363,9 +363,28 @@ void pci_bus_get_w64_range(PCIBus *bus, Range *range);
> >> void pci_device_deassert_intx(PCIDevice *dev);
> >> +typedef struct PCIAddressSpace {
> >> + AddressSpace *as;
> >
> > ... but here I fail to understand what is PCI specific in this
> > structure. You are just trying to an AS with a IOMMU MR, right?
> >
> Right. The patch is trying to better split the changes to use one function to
> return everything (via pci_device_iommu_info) with the PCIAddressSpace
> intermediate structure as retval, such that patch 3 just adds a
> IOMMUMemoryRegion* in the latter for usage with the
> pci_device_iommu_memory_region().
>
> I've named the structure with a 'PCI' prefix, because it seemed to me that it is
> the only case (AIUI) that cares about whether a PCI has a different address
> space that the memory map.
yea keep that pls. It should be possible to figure out the header
from the name.
> >> +} PCIAddressSpace;
> >> +
> >> typedef AddressSpace *(*PCIIOMMUFunc)(PCIBus *, void *, int);
> >> +static inline PCIAddressSpace as_to_pci_as(AddressSpace *as)
> >> +{
> >> + PCIAddressSpace ret = { .as = as };
> >> +
> >> + return ret;
> >> +}
> >> +static inline AddressSpace *pci_as_to_as(PCIAddressSpace pci_as)
> >> +{
> >> + return pci_as.as;
> >> +}
> >> +
> >> +PCIAddressSpace pci_device_iommu_info(PCIDevice *dev);
> >> +static inline AddressSpace *pci_device_iommu_address_space(PCIDevice *dev)
> >> +{
> >> + return pci_as_to_as(pci_device_iommu_info(dev));
> >> +}
> >> -AddressSpace *pci_device_iommu_address_space(PCIDevice *dev);
> >> void pci_setup_iommu(PCIBus *bus, PCIIOMMUFunc fn, void *opaque);
> >> pcibus_t pci_bar_address(PCIDevice *d,
> >
next prev parent reply other threads:[~2023-06-22 20:51 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 17:59 [PATCH v3 00/15] vfio: VFIO migration support with vIOMMU Joao Martins
2023-05-30 17:59 ` [PATCH v3 01/15] hw/pci: Refactor pci_device_iommu_address_space() Joao Martins
2023-05-30 22:04 ` Philippe Mathieu-Daudé
2023-05-31 10:03 ` Joao Martins
2023-06-22 20:50 ` Michael S. Tsirkin [this message]
2023-06-22 21:01 ` Joao Martins
2023-05-30 17:59 ` [PATCH v3 02/15] hw/pci: Add a pci_setup_iommu_info() helper Joao Martins
2023-05-30 17:59 ` [PATCH v3 03/15] hw/pci: Add a pci_device_iommu_memory_region() helper Joao Martins
2023-06-05 16:57 ` Peter Xu
2023-06-06 11:22 ` Joao Martins
2023-06-06 15:03 ` Peter Xu
2023-06-06 15:05 ` Peter Xu
2023-06-06 17:44 ` Joao Martins
2023-05-30 17:59 ` [PATCH v3 04/15] intel-iommu: Switch to pci_setup_iommu_info() Joao Martins
2023-05-30 17:59 ` [PATCH v3 05/15] vfio/common: Track the IOMMU MR behind the device in addition to the AS Joao Martins
2023-05-30 17:59 ` [PATCH v3 06/15] memory/iommu: Add IOMMU_ATTR_DMA_TRANSLATION attribute Joao Martins
2023-05-30 17:59 ` [PATCH v3 07/15] intel-iommu: Implement get_attr() method Joao Martins
2023-05-30 17:59 ` [PATCH v3 08/15] vfio/common: Relax vIOMMU detection when DMA translation is off Joao Martins
2023-05-30 21:39 ` Philippe Mathieu-Daudé
2023-05-31 9:39 ` Joao Martins
2023-05-30 17:59 ` [PATCH v3 09/15] memory/iommu: Add IOMMU_ATTR_MAX_IOVA attribute Joao Martins
2023-05-30 17:59 ` [PATCH v3 10/15] intel-iommu: Implement IOMMU_ATTR_MAX_IOVA get_attr() attribute Joao Martins
2023-05-30 21:45 ` Philippe Mathieu-Daudé
2023-05-31 9:54 ` Joao Martins
2023-05-31 13:59 ` Philippe Mathieu-Daudé
2023-05-30 17:59 ` [PATCH v3 11/15] vfio/common: Move dirty tracking ranges update to helper Joao Martins
2023-05-30 17:59 ` [PATCH v3 12/15] vfio/common: Support device dirty page tracking with vIOMMU Joao Martins
2023-05-30 17:59 ` [PATCH v3 13/15] vfio/common: Extract vIOMMU code from vfio_sync_dirty_bitmap() Joao Martins
2023-05-30 17:59 ` [PATCH v3 14/15] vfio/common: Optimize device dirty page tracking with vIOMMU Joao Martins
2023-05-30 17:59 ` [PATCH v3 15/15] vfio/common: Block migration with vIOMMUs without address width limits 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=20230622165003-mutt-send-email-mst@kernel.org \
--to=mst@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=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@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.