qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Cc: <qemu-arm@nongnu.org>, <qemu-devel@nongnu.org>,
	<eric.auger@redhat.com>, <peter.maydell@linaro.org>,
	<jgg@nvidia.com>, <ddutile@redhat.com>, <berrange@redhat.com>,
	<nathanc@nvidia.com>, <mochs@nvidia.com>, <smostafa@google.com>,
	<linuxarm@huawei.com>, <wangzhou1@hisilicon.com>,
	<jiangkunkun@huawei.com>, <jonathan.cameron@huawei.com>,
	<zhangfei.gao@linaro.org>, <zhenzhong.duan@intel.com>,
	<shameerkolothum@gmail.com>
Subject: Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd
Date: Tue, 5 Aug 2025 17:55:07 -0700	[thread overview]
Message-ID: <aJKn650gOGQh2whD@Asurada-Nvidia> (raw)
In-Reply-To: <20250714155941.22176-7-shameerali.kolothum.thodi@huawei.com>

Hi Shameer,

On Mon, Jul 14, 2025 at 04:59:32PM +0100, Shameer Kolothum wrote:
> @@ -25,30 +31,72 @@ static SMMUv3AccelDevice *smmuv3_accel_get_dev(SMMUState *bs, SMMUPciBus *sbus,
>  
>          sbus->pbdev[devfn] = sdev;
>          smmu_init_sdev(bs, sdev, bus, devfn);
> +        address_space_init(&accel_dev->as_sysmem, &s->s_accel->root,
> +                           "smmuv3-accel-sysmem");
>      }
>  
>      return accel_dev;
>  }
[..]
>  static AddressSpace *smmuv3_accel_find_add_as(PCIBus *bus, void *opaque,
>                                                int devfn)
>  {
> +    PCIDevice *pdev = pci_find_device(bus, pci_bus_num(bus), devfn);
>      SMMUState *bs = opaque;
> +    bool vfio_pci = false;
>      SMMUPciBus *sbus;
>      SMMUv3AccelDevice *accel_dev;
>      SMMUDevice *sdev;
>  
> +    if (pdev && !smmuv3_accel_pdev_allowed(pdev, &vfio_pci)) {
> +        error_report("Device(%s) not allowed. Only PCIe root complex devices "
> +                     "or PCI bridge devices or vfio-pci endpoint devices with "
> +                     "iommufd as backend is allowed with arm-smmuv3,accel=on",
> +                     pdev->name);
> +        exit(1);
> +    }
>      sbus = smmu_get_sbus(bs, bus);
>      accel_dev = smmuv3_accel_get_dev(bs, sbus, bus, devfn);
>      sdev = &accel_dev->sdev;
>  
> -    return &sdev->as;
> +    if (vfio_pci) {
> +        return &accel_dev->as_sysmem;

I found a new problem here that we initialize new as_sysmem per
VFIO device. So, sdevs would return own individual AS pointers
here at this get_address_space function, although they point to
the same system address space.

Since address space pointers are returned differently for VFIO
devices, this fails to reuse ioas_id in iommufd_cdev_attach(),
and ends up with allocating a new ioas for each device.

I think we can try the following change to make sure all accel
linked VFIO devices would share the same ioas_id, though I am
not sure if SMMUBaseClass is the right place to go. Please take
a look.

Then, once kernel is patched to share S2 hwpt across vSMMUs,
iommufd_cdev_attach() will go further to reuse the S2 HWPT in
the same container.

Thanks
Nicolin

---
 hw/arm/smmuv3-accel.c        | 14 ++++++++++----
 hw/arm/smmuv3-accel.h        |  2 +-
 include/hw/arm/smmu-common.h |  2 ++
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c
index c6dc50cf45..405b72095f 100644
--- a/hw/arm/smmuv3-accel.c
+++ b/hw/arm/smmuv3-accel.c
@@ -370,13 +370,19 @@ static SMMUv3AccelDevice *smmuv3_accel_get_dev(SMMUState *bs, SMMUPciBus *sbus,
     if (sdev) {
         accel_dev = container_of(sdev, SMMUv3AccelDevice, sdev);
     } else {
+        SMMUBaseClass *sbc = ARM_SMMU_GET_CLASS(s);
+
         accel_dev = g_new0(SMMUv3AccelDevice, 1);
         sdev = &accel_dev->sdev;
 
         sbus->pbdev[devfn] = sdev;
         smmu_init_sdev(bs, sdev, bus, devfn);
-        address_space_init(&accel_dev->as_sysmem, &s->s_accel->root,
-                           "smmuv3-accel-sysmem");
+        if (!sbc->as_sysmem) {
+            sbc->as_sysmem = g_new0(AddressSpace, 1);
+            address_space_init(sbc->as_sysmem, &s->s_accel->root,
+                               "smmuv3-accel-sysmem");
+        }
+        accel_dev->as_sysmem = sbc->as_sysmem;
     }
 
     return accel_dev;
@@ -558,7 +564,7 @@ static AddressSpace *smmuv3_accel_find_msi_as(PCIBus *bus, void *opaque,
     if (accel_dev->s1_hwpt) {
         return &sdev->as;
     } else {
-        return &accel_dev->as_sysmem;
+        return accel_dev->as_sysmem;
     }
 }
 
@@ -599,7 +605,7 @@ static AddressSpace *smmuv3_accel_find_add_as(PCIBus *bus, void *opaque,
     sdev = &accel_dev->sdev;
 
     if (vfio_pci) {
-        return &accel_dev->as_sysmem;
+        return accel_dev->as_sysmem;
     } else {
         return &sdev->as;
     }
diff --git a/hw/arm/smmuv3-accel.h b/hw/arm/smmuv3-accel.h
index e1e99598b4..9faa0818d7 100644
--- a/hw/arm/smmuv3-accel.h
+++ b/hw/arm/smmuv3-accel.h
@@ -37,7 +37,7 @@ typedef struct SMMUS1Hwpt {
 
 typedef struct SMMUv3AccelDevice {
     SMMUDevice  sdev;
-    AddressSpace as_sysmem;
+    AddressSpace *as_sysmem;
     HostIOMMUDeviceIOMMUFD *idev;
     SMMUS1Hwpt  *s1_hwpt;
     SMMUViommu *viommu;
diff --git a/include/hw/arm/smmu-common.h b/include/hw/arm/smmu-common.h
index c459d24427..9bb9554435 100644
--- a/include/hw/arm/smmu-common.h
+++ b/include/hw/arm/smmu-common.h
@@ -168,6 +168,8 @@ struct SMMUState {
 struct SMMUBaseClass {
     /* <private> */
     SysBusDeviceClass parent_class;
+    /* FIXME is there any better shared place for different vSMMU instances? */
+    AddressSpace *as_sysmem;
 
     /*< public >*/
 
-- 


  parent reply	other threads:[~2025-08-06  0:56 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-14 15:59 [RFC PATCH v3 00/15] hw/arm/virt: Add support for user-creatable accelerated SMMUv3 Shameer Kolothum via
2025-07-14 15:59 ` [RFC PATCH v3 01/15] backends/iommufd: Introduce iommufd_backend_alloc_viommu Shameer Kolothum via
2025-07-14 16:22   ` Nicolin Chen
2025-07-15  9:14   ` Jonathan Cameron via
2025-07-14 15:59 ` [RFC PATCH v3 02/15] backends/iommufd: Introduce iommufd_vdev_alloc Shameer Kolothum via
2025-07-14 16:27   ` Nicolin Chen
2025-07-15  9:19   ` Jonathan Cameron via
2025-07-14 15:59 ` [RFC PATCH v3 03/15] hw/arm/smmu-common: Factor out common helper functions and export Shameer Kolothum via
2025-07-15  9:27   ` Jonathan Cameron via
2025-07-14 15:59 ` [RFC PATCH v3 04/15] hw/arm/smmu-common: Introduce smmu_iommu_ops_by_type() helper Shameer Kolothum via
2025-07-14 16:38   ` Nicolin Chen via
2025-07-15  9:30   ` Jonathan Cameron via
2025-09-04  7:55   ` Eric Auger
2025-07-14 15:59 ` [RFC PATCH v3 05/15] hw/arm/smmuv3-accel: Introduce smmuv3 accel device Shameer Kolothum via
2025-07-14 17:23   ` Nicolin Chen
2025-09-04 14:33     ` Eric Auger
2025-09-05  8:22       ` Shameer Kolothum
2025-09-05 10:17         ` Eric Auger
2025-07-15  9:45   ` Jonathan Cameron via
2025-07-15 10:48   ` Duan, Zhenzhong
2025-07-15 17:29     ` Nicolin Chen
2025-07-16  3:38       ` Duan, Zhenzhong
2025-07-16  9:27         ` Shameerali Kolothum Thodi via
2025-09-04 14:31           ` Eric Auger
2025-07-14 15:59 ` [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd Shameer Kolothum via
2025-07-14 18:18   ` Nicolin Chen
2025-07-15  9:51   ` Jonathan Cameron via
2025-07-15 10:53   ` Duan, Zhenzhong
2025-07-15 17:59     ` Nicolin Chen
2025-07-16  6:26       ` Duan, Zhenzhong
2025-07-16  9:34         ` Shameerali Kolothum Thodi via
2025-07-16 10:32           ` Duan, Zhenzhong
2025-07-16 17:51           ` Nicolin Chen
2025-07-16 18:21             ` Nicolin Chen
2025-09-05  8:34             ` Eric Auger
2025-09-05  8:14         ` Eric Auger
2025-07-16  8:06       ` Shameerali Kolothum Thodi via
2025-09-05  8:29         ` Eric Auger
2025-08-06  0:55   ` Nicolin Chen [this message]
2025-09-05  8:42   ` Eric Auger
2025-07-14 15:59 ` [RFC PATCH v3 07/15] hw/arm/smmuv3: Implement get_viommu_cap() callback Shameer Kolothum via
2025-07-14 18:31   ` Nicolin Chen
2025-09-05  8:49   ` Eric Auger
2025-07-14 15:59 ` [RFC PATCH v3 08/15] hw/arm/smmuv3-accel: Add set/unset_iommu_device callback Shameer Kolothum via
2025-07-14 19:11   ` Nicolin Chen
2025-07-15 10:29   ` Jonathan Cameron via
2025-07-15 17:01     ` Nicolin Chen
2025-07-16  9:33       ` Jonathan Cameron via
2025-09-05  9:27   ` Eric Auger
2025-07-14 15:59 ` [RFC PATCH v3 09/15] hw/arm/smmuv3-accel: Support nested STE install/uninstall support Shameer Kolothum via
2025-07-14 19:37   ` Nicolin Chen
2025-07-15 23:12   ` Nicolin Chen
2025-07-16  8:36     ` Shameerali Kolothum Thodi via
2025-07-16 18:17       ` Nicolin Chen
2025-09-05  9:51       ` Eric Auger
2025-09-05  9:40   ` Eric Auger
2025-07-14 15:59 ` [RFC PATCH v3 10/15] hw/arm/smmuv3-accel: Allocate a vDEVICE object for device Shameer Kolothum via
2025-07-14 19:43   ` Nicolin Chen
2025-09-05  9:57   ` Eric Auger
2025-09-05 18:36     ` Nicolin Chen
2025-07-14 15:59 ` [RFC PATCH v3 11/15] hw/pci/pci: Introduce optional get_msi_address_space() callback Shameer Kolothum via
2025-07-14 19:50   ` Nicolin Chen
2025-09-05 10:11     ` Eric Auger
2025-09-05 10:11   ` Eric Auger
2025-07-14 15:59 ` [RFC PATCH v3 12/15] hw/arm/smmuv3-accel: Introduce helpers to batch and issue cache invalidations Shameer Kolothum via
2025-07-14 19:55   ` Nicolin Chen
2025-07-15 10:39   ` Jonathan Cameron via
2025-07-15 17:07     ` Nicolin Chen
2025-09-05 10:31   ` Eric Auger
2025-07-14 15:59 ` [RFC PATCH v3 13/15] hw/arm/smmuv3: Forward invalidation commands to hw Shameer Kolothum via
2025-07-15 10:46   ` Jonathan Cameron via
2025-07-15 17:22     ` Nicolin Chen
2025-07-16  7:32       ` Shameerali Kolothum Thodi via
2025-09-05 12:45   ` Eric Auger
2025-07-14 15:59 ` [RFC PATCH v3 14/15] Read and validate host SMMUv3 feature bits Shameer Kolothum via
2025-07-14 20:04   ` Nicolin Chen via
2025-07-14 20:24     ` Nicolin Chen via
2025-07-15 10:48   ` Jonathan Cameron via
2025-07-16  2:57   ` Nicolin Chen via
2025-07-16 10:26     ` Shameerali Kolothum Thodi via
2025-07-16 18:37       ` Nicolin Chen
2025-07-16 11:51     ` Jason Gunthorpe
2025-07-16 17:35       ` Nicolin Chen
2025-07-16 17:45         ` Jason Gunthorpe
2025-07-16 18:09           ` Nicolin Chen
2025-07-16 18:42             ` Jason Gunthorpe
2025-07-16 18:53               ` Nicolin Chen
2025-09-05 13:04           ` Eric Auger
2025-07-22 17:42   ` Nicolin Chen
2025-09-05 13:20   ` Eric Auger
2025-07-14 15:59 ` [RFC PATCH v3 15/15] hw/arm/smmu-common: Add accel property for SMMU dev Shameer Kolothum via
2025-07-14 20:00   ` Nicolin Chen
2025-07-15 10:49   ` Jonathan Cameron via
2025-09-05 10:36   ` Eric Auger
2025-07-14 16:14 ` [RFC PATCH v3 00/15] hw/arm/virt: Add support for user-creatable accelerated SMMUv3 Nicolin Chen via
2025-07-14 20:22   ` Nicolin Chen via
2025-07-15 10:46 ` Duan, Zhenzhong
2025-07-16  7:27   ` Shameerali Kolothum Thodi via

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=aJKn650gOGQh2whD@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=berrange@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=jiangkunkun@huawei.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linuxarm@huawei.com \
    --cc=mochs@nvidia.com \
    --cc=nathanc@nvidia.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=shameerkolothum@gmail.com \
    --cc=smostafa@google.com \
    --cc=wangzhou1@hisilicon.com \
    --cc=zhangfei.gao@linaro.org \
    --cc=zhenzhong.duan@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 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).