From: Jonathan Cameron via <qemu-arm@nongnu.org>
To: Shameer Kolothum <skolothumtho@nvidia.com>
Cc: <qemu-arm@nongnu.org>, <qemu-devel@nongnu.org>,
<eric.auger@redhat.com>, <peter.maydell@linaro.org>,
<jgg@nvidia.com>, <nicolinc@nvidia.com>, <ddutile@redhat.com>,
<berrange@redhat.com>, <nathanc@nvidia.com>, <mochs@nvidia.com>,
<smostafa@google.com>, <wangzhou1@hisilicon.com>,
<jiangkunkun@huawei.com>, <zhangfei.gao@linaro.org>,
<zhenzhong.duan@intel.com>, <yi.l.liu@intel.com>,
<kjaju@nvidia.com>
Subject: Re: [PATCH v5 23/32] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding
Date: Mon, 3 Nov 2025 14:53:52 +0000 [thread overview]
Message-ID: <20251103145352.00005c24@huawei.com> (raw)
In-Reply-To: <20251031105005.24618-24-skolothumtho@nvidia.com>
On Fri, 31 Oct 2025 10:49:56 +0000
Shameer Kolothum <skolothumtho@nvidia.com> wrote:
> From: Eric Auger <eric.auger@redhat.com>
>
> To handle SMMUv3 accel=on mode(which configures the host SMMUv3 in nested
> mode), it is practical to expose the guest with reserved memory regions
> (RMRs) covering the IOVAs used by the host kernel to map physical MSI
> doorbells.
>
> Those IOVAs belong to [0x8000000, 0x8100000] matching MSI_IOVA_BASE and
> MSI_IOVA_LENGTH definitions in kernel arm-smmu-v3 driver. This is the
> window used to allocate IOVAs matching physical MSI doorbells.
>
> With those RMRs, the guest is forced to use a flat mapping for this range.
> Hence the assigned device is programmed with one IOVA from this range.
> Stage 1, owned by the guest has a flat mapping for this IOVA. Stage2,
> owned by the VMM then enforces a mapping from this IOVA to the physical
> MSI doorbell.
>
> The creation of those RMR nodes is only relevant if nested stage SMMU is
> in use, along with VFIO. As VFIO devices can be hotplugged, all RMRs need
> to be created in advance.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Suggested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
One small question inline on the id increment.
With that tidied up.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> @@ -447,10 +475,70 @@ static void create_rc_its_idmaps(GArray *its_idmaps, GArray *smmuv3_devs)
> }
> }
>
> +static void
> +build_iort_rmr_nodes(GArray *table_data, GArray *smmuv3_devices, uint32_t *id)
> +{
> + AcpiIortSMMUv3Dev *sdev;
> + AcpiIortIdMapping *idmap;
> + int i;
> +
> + for (i = 0; i < smmuv3_devices->len; i++) {
> + uint16_t rmr_len;
> + int bdf;
> +
> + sdev = &g_array_index(smmuv3_devices, AcpiIortSMMUv3Dev, i);
> + if (!sdev->accel) {
> + continue;
> + }
> +
> + /*
> + * Spec reference:Arm IO Remapping Table(IORT), ARM DEN 0049E.d,
> + * Section 3.1.1.5 "Reserved Memory Range node"
> + */
> + idmap = &g_array_index(sdev->rc_smmu_idmaps, AcpiIortIdMapping, 0);
> + bdf = idmap->input_base;
> + rmr_len = IORT_RMR_COMMON_HEADER_SIZE
> + + (IORT_RMR_NUM_ID_MAPPINGS * ID_MAPPING_ENTRY_SIZE)
> + + (IORT_RMR_NUM_MEM_RANGE_DESC * IORT_RMR_MEM_RANGE_DESC_SIZE);
> +
> + /* Table 18 Reserved Memory Range Node */
> + build_append_int_noprefix(table_data, 6 /* RMR */, 1); /* Type */
> + /* Length */
> + build_append_int_noprefix(table_data, rmr_len, 2);
> + build_append_int_noprefix(table_data, 3, 1); /* Revision */
> + build_append_int_noprefix(table_data, (*id)++, 4); /* Identifier */
So *id is incremented here and...
> + /* Number of ID mappings */
> + build_append_int_noprefix(table_data, IORT_RMR_NUM_ID_MAPPINGS, 4);
> + /* Reference to ID Array */
> + build_append_int_noprefix(table_data, IORT_RMR_COMMON_HEADER_SIZE, 4);
> +
> + /* RMR specific data */
> +
> + /* Flags */
> + build_append_int_noprefix(table_data, IORT_RMR_FLAGS, 4);
> + /* Number of Memory Range Descriptors */
> + build_append_int_noprefix(table_data, IORT_RMR_NUM_MEM_RANGE_DESC, 4);
> + /* Reference to Memory Range Descriptors */
> + build_append_int_noprefix(table_data, IORT_RMR_COMMON_HEADER_SIZE +
> + (IORT_RMR_NUM_ID_MAPPINGS * ID_MAPPING_ENTRY_SIZE), 4);
> + build_iort_id_mapping(table_data, bdf, idmap->id_count, sdev->offset,
> + 1);
> +
> + /* Table 19 Memory Range Descriptor */
> +
> + /* Physical Range offset */
> + build_append_int_noprefix(table_data, MSI_IOVA_BASE, 8);
> + /* Physical Range length */
> + build_append_int_noprefix(table_data, MSI_IOVA_LENGTH, 8);
> + build_append_int_noprefix(table_data, 0, 4); /* Reserved */
> + *id += 1;
here. Why this second one? Perhaps a comment if this is intended.
> + }
> +}
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Shameer Kolothum <skolothumtho@nvidia.com>
Cc: <qemu-arm@nongnu.org>, <qemu-devel@nongnu.org>,
<eric.auger@redhat.com>, <peter.maydell@linaro.org>,
<jgg@nvidia.com>, <nicolinc@nvidia.com>, <ddutile@redhat.com>,
<berrange@redhat.com>, <nathanc@nvidia.com>, <mochs@nvidia.com>,
<smostafa@google.com>, <wangzhou1@hisilicon.com>,
<jiangkunkun@huawei.com>, <zhangfei.gao@linaro.org>,
<zhenzhong.duan@intel.com>, <yi.l.liu@intel.com>,
<kjaju@nvidia.com>
Subject: Re: [PATCH v5 23/32] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding
Date: Mon, 3 Nov 2025 14:53:52 +0000 [thread overview]
Message-ID: <20251103145352.00005c24@huawei.com> (raw)
In-Reply-To: <20251031105005.24618-24-skolothumtho@nvidia.com>
On Fri, 31 Oct 2025 10:49:56 +0000
Shameer Kolothum <skolothumtho@nvidia.com> wrote:
> From: Eric Auger <eric.auger@redhat.com>
>
> To handle SMMUv3 accel=on mode(which configures the host SMMUv3 in nested
> mode), it is practical to expose the guest with reserved memory regions
> (RMRs) covering the IOVAs used by the host kernel to map physical MSI
> doorbells.
>
> Those IOVAs belong to [0x8000000, 0x8100000] matching MSI_IOVA_BASE and
> MSI_IOVA_LENGTH definitions in kernel arm-smmu-v3 driver. This is the
> window used to allocate IOVAs matching physical MSI doorbells.
>
> With those RMRs, the guest is forced to use a flat mapping for this range.
> Hence the assigned device is programmed with one IOVA from this range.
> Stage 1, owned by the guest has a flat mapping for this IOVA. Stage2,
> owned by the VMM then enforces a mapping from this IOVA to the physical
> MSI doorbell.
>
> The creation of those RMR nodes is only relevant if nested stage SMMU is
> in use, along with VFIO. As VFIO devices can be hotplugged, all RMRs need
> to be created in advance.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Suggested-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
One small question inline on the id increment.
With that tidied up.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> @@ -447,10 +475,70 @@ static void create_rc_its_idmaps(GArray *its_idmaps, GArray *smmuv3_devs)
> }
> }
>
> +static void
> +build_iort_rmr_nodes(GArray *table_data, GArray *smmuv3_devices, uint32_t *id)
> +{
> + AcpiIortSMMUv3Dev *sdev;
> + AcpiIortIdMapping *idmap;
> + int i;
> +
> + for (i = 0; i < smmuv3_devices->len; i++) {
> + uint16_t rmr_len;
> + int bdf;
> +
> + sdev = &g_array_index(smmuv3_devices, AcpiIortSMMUv3Dev, i);
> + if (!sdev->accel) {
> + continue;
> + }
> +
> + /*
> + * Spec reference:Arm IO Remapping Table(IORT), ARM DEN 0049E.d,
> + * Section 3.1.1.5 "Reserved Memory Range node"
> + */
> + idmap = &g_array_index(sdev->rc_smmu_idmaps, AcpiIortIdMapping, 0);
> + bdf = idmap->input_base;
> + rmr_len = IORT_RMR_COMMON_HEADER_SIZE
> + + (IORT_RMR_NUM_ID_MAPPINGS * ID_MAPPING_ENTRY_SIZE)
> + + (IORT_RMR_NUM_MEM_RANGE_DESC * IORT_RMR_MEM_RANGE_DESC_SIZE);
> +
> + /* Table 18 Reserved Memory Range Node */
> + build_append_int_noprefix(table_data, 6 /* RMR */, 1); /* Type */
> + /* Length */
> + build_append_int_noprefix(table_data, rmr_len, 2);
> + build_append_int_noprefix(table_data, 3, 1); /* Revision */
> + build_append_int_noprefix(table_data, (*id)++, 4); /* Identifier */
So *id is incremented here and...
> + /* Number of ID mappings */
> + build_append_int_noprefix(table_data, IORT_RMR_NUM_ID_MAPPINGS, 4);
> + /* Reference to ID Array */
> + build_append_int_noprefix(table_data, IORT_RMR_COMMON_HEADER_SIZE, 4);
> +
> + /* RMR specific data */
> +
> + /* Flags */
> + build_append_int_noprefix(table_data, IORT_RMR_FLAGS, 4);
> + /* Number of Memory Range Descriptors */
> + build_append_int_noprefix(table_data, IORT_RMR_NUM_MEM_RANGE_DESC, 4);
> + /* Reference to Memory Range Descriptors */
> + build_append_int_noprefix(table_data, IORT_RMR_COMMON_HEADER_SIZE +
> + (IORT_RMR_NUM_ID_MAPPINGS * ID_MAPPING_ENTRY_SIZE), 4);
> + build_iort_id_mapping(table_data, bdf, idmap->id_count, sdev->offset,
> + 1);
> +
> + /* Table 19 Memory Range Descriptor */
> +
> + /* Physical Range offset */
> + build_append_int_noprefix(table_data, MSI_IOVA_BASE, 8);
> + /* Physical Range length */
> + build_append_int_noprefix(table_data, MSI_IOVA_LENGTH, 8);
> + build_append_int_noprefix(table_data, 0, 4); /* Reserved */
> + *id += 1;
here. Why this second one? Perhaps a comment if this is intended.
> + }
> +}
next prev parent reply other threads:[~2025-11-03 14:54 UTC|newest]
Thread overview: 172+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 10:49 [PATCH v5 00/32] hw/arm/virt: Add support for user-creatable accelerated SMMUv3 Shameer Kolothum
2025-10-31 10:49 ` [PATCH v5 01/32] backends/iommufd: Introduce iommufd_backend_alloc_viommu Shameer Kolothum
2025-10-31 10:49 ` [PATCH v5 02/32] backends/iommufd: Introduce iommufd_backend_alloc_vdev Shameer Kolothum
2025-10-31 10:49 ` [PATCH v5 03/32] hw/arm/smmu-common: Factor out common helper functions and export Shameer Kolothum
2025-10-31 10:49 ` [PATCH v5 04/32] hw/arm/smmu-common: Make iommu ops part of SMMUState Shameer Kolothum
2025-10-31 10:49 ` [PATCH v5 05/32] hw/arm/smmuv3-accel: Introduce smmuv3 accel device Shameer Kolothum
2025-10-31 10:49 ` [PATCH v5 06/32] hw/arm/smmuv3-accel: Initialize shared system address space Shameer Kolothum
2025-10-31 21:10 ` Nicolin Chen
2025-11-03 14:17 ` Shameer Kolothum
2025-11-03 13:12 ` Jonathan Cameron via
2025-11-03 13:12 ` Jonathan Cameron via
2025-11-03 15:53 ` Shameer Kolothum
2025-11-03 13:39 ` Philippe Mathieu-Daudé
2025-11-03 16:30 ` Eric Auger
2025-10-31 10:49 ` [PATCH v5 07/32] hw/pci/pci: Move pci_init_bus_master() after adding device to bus Shameer Kolothum
2025-11-03 13:24 ` Jonathan Cameron via
2025-11-03 13:24 ` Jonathan Cameron via
2025-11-03 16:40 ` Eric Auger
2025-10-31 10:49 ` [PATCH v5 08/32] hw/pci/pci: Add optional supports_address_space() callback Shameer Kolothum
2025-11-03 13:30 ` Jonathan Cameron via
2025-11-03 13:30 ` Jonathan Cameron via
2025-11-03 16:47 ` Eric Auger
2025-10-31 10:49 ` [PATCH v5 09/32] hw/pci-bridge/pci_expander_bridge: Move TYPE_PXB_PCIE_DEV to header Shameer Kolothum
2025-11-03 13:30 ` Jonathan Cameron via
2025-11-03 13:30 ` Jonathan Cameron via
2025-11-03 14:25 ` Eric Auger
2025-10-31 10:49 ` [PATCH v5 10/32] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd Shameer Kolothum
2025-11-03 16:51 ` Eric Auger
2025-10-31 10:49 ` [PATCH v5 11/32] hw/arm/smmuv3: Implement get_viommu_cap() callback Shameer Kolothum
2025-11-03 16:55 ` Eric Auger
2025-10-31 10:49 ` [PATCH v5 12/32] hw/arm/smmuv3-accel: Add set/unset_iommu_device callback Shameer Kolothum
2025-10-31 22:02 ` Nicolin Chen
2025-10-31 22:08 ` Nicolin Chen
2025-11-03 14:19 ` Shameer Kolothum
2025-10-31 10:49 ` [PATCH v5 13/32] hw/arm/smmuv3-accel: Add nested vSTE install/uninstall support Shameer Kolothum
2025-10-31 23:52 ` Nicolin Chen
2025-11-01 0:20 ` Nicolin Chen
2025-11-03 15:11 ` Shameer Kolothum
2025-11-03 17:32 ` Nicolin Chen
2025-11-04 11:05 ` Eric Auger
2025-11-04 12:26 ` Shameer Kolothum
2025-11-04 13:30 ` Eric Auger
2025-11-04 16:48 ` Nicolin Chen
2025-10-31 10:49 ` [PATCH v5 14/32] hw/arm/smmuv3-accel: Install SMMUv3 GBPA based hwpt Shameer Kolothum
2025-11-04 13:28 ` Eric Auger
2025-11-18 3:49 ` Zhangfei Gao
2025-11-18 7:56 ` Shameer Kolothum
2025-11-18 9:47 ` Zhangfei Gao
2025-10-31 10:49 ` [PATCH v5 15/32] hw/pci/pci: Introduce optional get_msi_address_space() callback Shameer Kolothum
2025-11-04 14:11 ` Eric Auger
2025-11-04 14:20 ` Jason Gunthorpe
2025-11-04 14:42 ` Shameer Kolothum
2025-11-04 14:51 ` Jason Gunthorpe
2025-11-04 14:58 ` Shameer Kolothum
2025-11-04 15:12 ` Jason Gunthorpe
2025-11-04 15:20 ` Shameer Kolothum
2025-11-04 15:35 ` Jason Gunthorpe
2025-11-04 17:11 ` Nicolin Chen
2025-11-04 17:41 ` Jason Gunthorpe
2025-11-04 17:57 ` Nicolin Chen
2025-11-04 18:09 ` Jason Gunthorpe
2025-11-04 18:44 ` Nicolin Chen
2025-11-04 18:56 ` Jason Gunthorpe
2025-11-04 19:31 ` Nicolin Chen
2025-11-04 19:35 ` Jason Gunthorpe
2025-11-04 19:43 ` Nicolin Chen
2025-11-04 19:45 ` Jason Gunthorpe
2025-11-04 19:59 ` Nicolin Chen
2025-11-04 19:46 ` Shameer Kolothum
2025-11-05 12:52 ` Jason Gunthorpe
2025-11-05 17:32 ` Eric Auger
2025-11-04 14:37 ` Shameer Kolothum
2025-11-04 14:44 ` Eric Auger
2025-11-04 15:14 ` Shameer Kolothum
2025-11-04 16:01 ` Eric Auger
2025-11-04 17:47 ` Nicolin Chen
2025-11-05 7:47 ` Eric Auger
2025-11-05 19:30 ` Nicolin Chen
2025-11-04 19:08 ` Shameer Kolothum
2025-11-05 8:56 ` Eric Auger
2025-11-05 11:41 ` Shameer Kolothum
2025-11-05 17:25 ` Eric Auger
2025-11-05 18:10 ` Jason Gunthorpe
2025-11-05 18:33 ` Nicolin Chen
2025-11-05 18:58 ` Jason Gunthorpe
2025-11-05 19:33 ` Nicolin Chen
2025-11-06 7:42 ` Eric Auger
2025-11-06 11:48 ` Shameer Kolothum
2025-11-06 17:04 ` Eric Auger
2025-11-07 10:27 ` Shameer Kolothum
2025-11-06 14:32 ` Jason Gunthorpe
2025-11-06 15:47 ` Eric Auger
2025-11-05 18:33 ` Shameer Kolothum
2025-10-31 10:49 ` [PATCH v5 16/32] hw/arm/smmuv3-accel: Make use of " Shameer Kolothum
2025-10-31 23:57 ` Nicolin Chen
2025-11-03 15:19 ` Shameer Kolothum
2025-11-03 17:34 ` Nicolin Chen
2025-10-31 10:49 ` [PATCH v5 17/32] hw/arm/smmuv3-accel: Add support to issue invalidation cmd to host Shameer Kolothum
2025-11-01 0:35 ` Nicolin Chen via
2025-11-01 0:35 ` Nicolin Chen via
2025-11-03 15:28 ` Shameer Kolothum
2025-11-03 17:43 ` Nicolin Chen
2025-11-03 18:17 ` Shameer Kolothum
2025-11-03 18:51 ` Nicolin Chen
2025-11-04 8:55 ` Eric Auger
2025-11-04 16:41 ` Nicolin Chen
2025-11-03 17:11 ` Eric Auger
2025-10-31 10:49 ` [PATCH v5 18/32] hw/arm/smmuv3: Initialize ID registers early during realize() Shameer Kolothum
2025-11-01 0:24 ` Nicolin Chen
2025-11-03 13:57 ` Jonathan Cameron via
2025-11-03 13:57 ` Jonathan Cameron via
2025-11-03 15:11 ` Eric Auger
2025-10-31 10:49 ` [PATCH v5 19/32] hw/arm/smmuv3-accel: Get host SMMUv3 hw info and validate Shameer Kolothum
2025-11-01 0:49 ` Nicolin Chen
2025-11-01 14:20 ` Zhangfei Gao
2025-11-03 15:42 ` Shameer Kolothum
2025-11-03 17:16 ` Eric Auger
2025-11-03 14:47 ` Jonathan Cameron via
2025-11-03 14:47 ` Jonathan Cameron via
2025-10-31 10:49 ` [PATCH v5 20/32] hw/pci-host/gpex: Allow to generate preserve boot config DSM #5 Shameer Kolothum
2025-11-03 13:58 ` Jonathan Cameron via
2025-11-03 13:58 ` Jonathan Cameron via
2025-10-31 10:49 ` [PATCH v5 21/32] hw/arm/virt: Set PCI preserve_config for accel SMMUv3 Shameer Kolothum
2025-11-03 14:58 ` Eric Auger
2025-11-03 15:03 ` Eric Auger via
2025-11-03 15:03 ` Eric Auger via
2025-11-03 16:01 ` Shameer Kolothum
2025-10-31 10:49 ` [PATCH v5 22/32] tests/qtest/bios-tables-test: Prepare for IORT revison upgrade Shameer Kolothum
2025-11-03 14:48 ` Jonathan Cameron via
2025-11-03 14:48 ` Jonathan Cameron via
2025-11-03 14:59 ` Eric Auger
2025-10-31 10:49 ` [PATCH v5 23/32] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding Shameer Kolothum
2025-11-03 14:53 ` Jonathan Cameron via [this message]
2025-11-03 14:53 ` Jonathan Cameron via
2025-11-03 15:43 ` Shameer Kolothum
2025-10-31 10:49 ` [PATCH v5 24/32] tests/qtest/bios-tables-test: Update IORT blobs after revision upgrade Shameer Kolothum
2025-11-03 14:54 ` Jonathan Cameron via
2025-11-03 14:54 ` Jonathan Cameron via
2025-11-03 15:01 ` Eric Auger
2025-10-31 10:49 ` [PATCH v5 25/32] hw/arm/smmuv3: Add accel property for SMMUv3 device Shameer Kolothum
2025-11-03 14:56 ` Jonathan Cameron via
2025-11-03 14:56 ` Jonathan Cameron via
2025-10-31 10:49 ` [PATCH v5 26/32] hw/arm/smmuv3-accel: Add a property to specify RIL support Shameer Kolothum
2025-11-03 15:07 ` Eric Auger
2025-11-03 16:08 ` Shameer Kolothum
2025-11-03 16:25 ` Eric Auger
2025-11-04 9:38 ` Eric Auger
2025-10-31 10:50 ` [PATCH v5 27/32] hw/arm/smmuv3-accel: Add support for ATS Shameer Kolothum
2025-11-04 14:22 ` Eric Auger
2025-10-31 10:50 ` [PATCH v5 28/32] hw/arm/smmuv3-accel: Add property to specify OAS bits Shameer Kolothum
2025-11-04 14:35 ` Eric Auger
2025-11-04 14:50 ` Jason Gunthorpe
2025-11-06 7:54 ` Eric Auger
2025-10-31 10:50 ` [PATCH v5 29/32] backends/iommufd: Retrieve PASID width from iommufd_backend_get_device_info() Shameer Kolothum
2025-10-31 10:50 ` [PATCH v5 30/32] Extend get_cap() callback to support PASID Shameer Kolothum
2025-11-03 14:58 ` Jonathan Cameron via
2025-11-03 14:58 ` Jonathan Cameron via
2025-11-06 8:45 ` Eric Auger
2025-10-31 10:50 ` [PATCH v5 31/32] vfio: Synthesize vPASID capability to VM Shameer Kolothum
2025-11-03 15:00 ` Jonathan Cameron via
2025-11-03 15:00 ` Jonathan Cameron via
2025-11-06 13:55 ` Eric Auger
2025-11-06 14:27 ` Shameer Kolothum
2025-11-06 15:44 ` Eric Auger
2025-12-09 10:10 ` Cédric Le Goater
2025-12-10 14:38 ` Shameer Kolothum
2025-12-10 15:15 ` Cédric Le Goater
2025-12-10 15:40 ` Cédric Le Goater
2025-10-31 10:50 ` [PATCH v5 32/32] hw/arm/smmuv3-accel: Add support for PASID enable Shameer Kolothum
2025-11-06 16:46 ` Eric Auger
2025-12-09 10:07 ` [PATCH v5 00/32] hw/arm/virt: Add support for user-creatable accelerated SMMUv3 Cédric Le Goater
2025-12-10 13:48 ` 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=20251103145352.00005c24@huawei.com \
--to=qemu-arm@nongnu.org \
--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=kjaju@nvidia.com \
--cc=mochs@nvidia.com \
--cc=nathanc@nvidia.com \
--cc=nicolinc@nvidia.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=skolothumtho@nvidia.com \
--cc=smostafa@google.com \
--cc=wangzhou1@hisilicon.com \
--cc=yi.l.liu@intel.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 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.