qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Joao Martins <joao.m.martins@oracle.com>
To: 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>,
	Joao Martins <joao.m.martins@oracle.com>
Subject: [PATCH v3 03/15] hw/pci: Add a pci_device_iommu_memory_region() helper
Date: Tue, 30 May 2023 18:59:25 +0100	[thread overview]
Message-ID: <20230530175937.24202-4-joao.m.martins@oracle.com> (raw)
In-Reply-To: <20230530175937.24202-1-joao.m.martins@oracle.com>

Today's VFIO model of understanding if an IOMMU is behind the PCIDevice
is to check whether the address space backing the device is memory or
not, which is done via pci_device_iommu_address_space(pdev).

On the other hand, the IOMMU MR is used for example to fetch attributes,
or when doing an vIOMMU map and figuring out if it's under the vIOMMU.
However, such object is only available today by the time the IOMMU map
notifier is called which depends on the guest doing a DMA map or not.
Thus there's no way to get access to the IOMMU memory region early i.e.
at vfio device initialization where we attest migration support and
impose LM blockers or not.

Much like pci_device_iommu_address_space() fetches the IOMMU AS, add a
pci_device_iommu_memory_region() which lets it return an the IOMMU MR
associated with it. The IOMMU MR is returned correctly for vIOMMUs using
pci_setup_iommu_info(). Note that today most vIOMMUs create the address
space and IOMMU MR at the same time, it's just mainly that there's API
to make the latter available.

This is in preparation for VFIO to track both the AS and IOMMU MR into
VFIOSpace without being tied to a map taking place by the guest. The
IOMMU MR will then provide access to upper layers about various IOMMU
attributes.

Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
---
 include/hw/pci/pci.h | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index d2c87d87a24e..0177f50e96a3 100644
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -365,13 +365,14 @@ void pci_device_deassert_intx(PCIDevice *dev);
 
 typedef struct PCIAddressSpace {
     AddressSpace *as;
+    IOMMUMemoryRegion *iommu_mr;
 } PCIAddressSpace;
 
 typedef AddressSpace *(*PCIIOMMUFunc)(PCIBus *, void *, int);
 typedef PCIAddressSpace (*PCIIOMMUASFunc)(PCIBus *, void *, int);
 static inline PCIAddressSpace as_to_pci_as(AddressSpace *as)
 {
-    PCIAddressSpace ret = { .as = as };
+    PCIAddressSpace ret = { .as = as, .iommu_mr = NULL };
 
     return ret;
 }
@@ -379,6 +380,13 @@ static inline AddressSpace *pci_as_to_as(PCIAddressSpace pci_as)
 {
     return pci_as.as;
 }
+static inline PCIAddressSpace to_pci_as(AddressSpace *as,
+                                        IOMMUMemoryRegion *iommu_mr)
+{
+    PCIAddressSpace ret = { .as = as, .iommu_mr = iommu_mr };
+
+    return ret;
+}
 
 PCIAddressSpace pci_device_iommu_info(PCIDevice *dev);
 static inline AddressSpace *pci_device_iommu_address_space(PCIDevice *dev)
@@ -386,6 +394,13 @@ static inline AddressSpace *pci_device_iommu_address_space(PCIDevice *dev)
     return pci_as_to_as(pci_device_iommu_info(dev));
 }
 
+static inline IOMMUMemoryRegion *pci_device_iommu_memory_region(PCIDevice *dev)
+{
+    PCIAddressSpace ret = pci_device_iommu_info(dev);
+
+    return ret.iommu_mr;
+}
+
 void pci_setup_iommu(PCIBus *bus, PCIIOMMUFunc fn, void *opaque);
 void pci_setup_iommu_info(PCIBus *bus, PCIIOMMUASFunc fn, void *opaque);
 
-- 
2.39.3



  parent reply	other threads:[~2023-05-30 18:05 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
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 ` Joao Martins [this message]
2023-06-05 16:57   ` [PATCH v3 03/15] hw/pci: Add a pci_device_iommu_memory_region() helper 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=20230530175937.24202-4-joao.m.martins@oracle.com \
    --to=joao.m.martins@oracle.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=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 \
    /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).