qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Shameer Kolothum <skolothumtho@nvidia.com>
To: <qemu-arm@nongnu.org>, <qemu-devel@nongnu.org>
Cc: <eric.auger@redhat.com>, <peter.maydell@linaro.org>,
	<nicolinc@nvidia.com>, <nathanc@nvidia.com>, <mochs@nvidia.com>,
	<jgg@nvidia.com>, <jonathan.cameron@huawei.com>,
	<zhangfei.gao@linaro.org>, <zhenzhong.duan@intel.com>,
	<kjaju@nvidia.com>
Subject: [RFC PATCH 01/16] backends/iommufd: Update iommufd_backend_get_device_info
Date: Wed, 10 Dec 2025 13:37:22 +0000	[thread overview]
Message-ID: <20251210133737.78257-2-skolothumtho@nvidia.com> (raw)
In-Reply-To: <20251210133737.78257-1-skolothumtho@nvidia.com>

From: Nicolin Chen <nicolinc@nvidia.com>

The updated IOMMUFD uAPI introduces the ability for userspace to request
a specific hardware info data type via IOMMU_GET_HW_INFO. Update
iommufd_backend_get_device_info() to set IOMMU_HW_INFO_FLAG_INPUT_TYPE
when a non-zero type is supplied, and adjust all callers to pass an
explicitly initialised type value.

Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
---
 backends/iommufd.c    | 7 +++++++
 hw/arm/smmuv3-accel.c | 2 +-
 hw/vfio/iommufd.c     | 6 ++----
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/backends/iommufd.c b/backends/iommufd.c
index 633aecd525..938c8fe669 100644
--- a/backends/iommufd.c
+++ b/backends/iommufd.c
@@ -386,16 +386,23 @@ bool iommufd_backend_get_dirty_bitmap(IOMMUFDBackend *be,
     return true;
 }
 
+/*
+ * @type can carry a desired HW info type defined in the uapi headers. If caller
+ * doesn't have one, indicating it wants the default type, then @type should be
+ * zeroed (i.e. IOMMU_HW_INFO_TYPE_DEFAULT).
+ */
 bool iommufd_backend_get_device_info(IOMMUFDBackend *be, uint32_t devid,
                                      uint32_t *type, void *data, uint32_t len,
                                      uint64_t *caps, uint8_t *max_pasid_log2,
                                      Error **errp)
 {
     struct iommu_hw_info info = {
+        .flags = (*type) ? IOMMU_HW_INFO_FLAG_INPUT_TYPE : 0,
         .size = sizeof(info),
         .dev_id = devid,
         .data_len = len,
         .data_uptr = (uintptr_t)data,
+        .in_data_type = *type,
     };
 
     if (ioctl(be->fd, IOMMU_GET_HW_INFO, &info)) {
diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c
index d320c62b04..300c35ccb5 100644
--- a/hw/arm/smmuv3-accel.c
+++ b/hw/arm/smmuv3-accel.c
@@ -115,7 +115,7 @@ smmuv3_accel_hw_compatible(SMMUv3State *s, HostIOMMUDeviceIOMMUFD *idev,
                            Error **errp)
 {
     struct iommu_hw_info_arm_smmuv3 info;
-    uint32_t data_type;
+    uint32_t data_type = 0;
     uint64_t caps;
 
     if (!iommufd_backend_get_device_info(idev->iommufd, idev->devid, &data_type,
diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c
index bbe944d7cc..670bdfc53b 100644
--- a/hw/vfio/iommufd.c
+++ b/hw/vfio/iommufd.c
@@ -306,7 +306,7 @@ static bool iommufd_cdev_autodomains_get(VFIODevice *vbasedev,
     ERRP_GUARD();
     IOMMUFDBackend *iommufd = vbasedev->iommufd;
     VFIOContainer *bcontainer = VFIO_IOMMU(container);
-    uint32_t type, flags = 0;
+    uint32_t type = 0, flags = 0;
     uint64_t hw_caps;
     VFIOIOASHwpt *hwpt;
     uint32_t hwpt_id;
@@ -631,8 +631,6 @@ skip_ioas_alloc:
     bcontainer->initialized = true;
 
 found_container:
-    vbasedev->cpr.ioas_id = container->ioas_id;
-
     ret = ioctl(devfd, VFIO_DEVICE_GET_INFO, &dev_info);
     if (ret) {
         error_setg_errno(errp, errno, "error getting device info");
@@ -889,7 +887,7 @@ static bool hiod_iommufd_vfio_realize(HostIOMMUDevice *hiod, void *opaque,
     HostIOMMUDeviceIOMMUFD *idev;
     HostIOMMUDeviceCaps *caps = &hiod->caps;
     VendorCaps *vendor_caps = &caps->vendor_caps;
-    enum iommu_hw_info_type type;
+    enum iommu_hw_info_type type = 0;
     uint8_t max_pasid_log2;
     uint64_t hw_caps;
 
-- 
2.43.0



  reply	other threads:[~2025-12-10 13:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-10 13:37 [RFC PATCH 00/16] hw/arm: Introduce Tegra241 CMDQV support for accelerated SMMUv3 Shameer Kolothum
2025-12-10 13:37 ` Shameer Kolothum [this message]
2025-12-10 13:37 ` [RFC PATCH 02/16] backends/iommufd: Update iommufd_backend_alloc_viommu to allow user ptr Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 03/16] backends/iommufd: Introduce iommufd_backend_alloc_hw_queue Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 04/16] backends/iommufd: Introduce iommufd_backend_viommu_mmap Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 05/16] hw/arm/tegra241-cmdqv: Add initial Tegra241 CMDQ-Virtualisation support Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 06/16] hw/arm/tegra241-cmdqv: Map VINTF Page0 into guest Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 07/16] hw/arm/tegra241-cmdqv: Add read emulation support for registers Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 08/16] system/physmem: Add helper to check whether a guest PA maps to RAM Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 09/16] hw/arm/tegra241-cmdqv:: Add write emulation for registers Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 10/16] hw/arm/tegra241-cmdqv: Allocate vEVENTQ object Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 11/16] hw/arm/tegra241-cmdqv: Read and propagate Tegra241 CMDQV errors Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 12/16] hw/arm/tegra241-cmdqv: Add reset handler Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 13/16] hw/arm/tegra241-cmdqv: Limit queue size based on backend page size Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 14/16] virt-acpi-build: Rename AcpiIortSMMUv3Dev to AcpiSMMUv3Dev Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 15/16] hw/arm/virt-acpi: Advertise Tegra241 CMDQV nodes in DSDT Shameer Kolothum
2025-12-10 13:37 ` [RFC PATCH 16/16] hw/arm/smmuv3: Add tegra241-cmdqv property for SMMUv3 device Shameer Kolothum
2025-12-11 17:54 ` [RFC PATCH 00/16] hw/arm: Introduce Tegra241 CMDQV support for accelerated SMMUv3 Eric Auger
2025-12-12  0:23   ` Shameer Kolothum

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=20251210133737.78257-2-skolothumtho@nvidia.com \
    --to=skolothumtho@nvidia.com \
    --cc=eric.auger@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kjaju@nvidia.com \
    --cc=mochs@nvidia.com \
    --cc=nathanc@nvidia.com \
    --cc=nicolinc@nvidia.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --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).