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>, <clg@redhat.com>, <alex@shazbot.org>,
<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 v7 30/36] hw/arm/smmuv3-accel: Add property to specify OAS bits
Date: Wed, 14 Jan 2026 11:19:52 +0000 [thread overview]
Message-ID: <20260114111952.0000228a@huawei.com> (raw)
In-Reply-To: <20260111195508.106943-31-skolothumtho@nvidia.com>
On Sun, 11 Jan 2026 19:53:16 +0000
Shameer Kolothum <skolothumtho@nvidia.com> wrote:
> QEMU SMMUv3 currently sets the output address size (OAS) to 44 bits.
> With accelerator mode enabled, a device may use SVA, where CPU page tables
> are shared with the SMMU, requiring an OAS at least as large as the
> CPU’s output address size. A user option is added to configure this.
>
> However, the OAS value advertised by the virtual SMMU must remain
> compatible with the capabilities of the host SMMUv3. In accelerated
> mode, the host SMMU performs stage-2 translation and must be able to
> consume the intermediate physical addresses (IPA) produced by stage-1.
>
> The OAS exposed by the virtual SMMU defines the maximum IPA width that
> stage-1 translations may generate. For AArch64 implementations, the
> maximum usable IPA size on the host SMMU is determined by its own OAS.
> Check that the configured OAS does not exceed what the host SMMU
> can safely support.
>
> Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via qemu development <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>, <clg@redhat.com>, <alex@shazbot.org>,
<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 v7 30/36] hw/arm/smmuv3-accel: Add property to specify OAS bits
Date: Wed, 14 Jan 2026 11:19:52 +0000 [thread overview]
Message-ID: <20260114111952.0000228a@huawei.com> (raw)
In-Reply-To: <20260111195508.106943-31-skolothumtho@nvidia.com>
On Sun, 11 Jan 2026 19:53:16 +0000
Shameer Kolothum <skolothumtho@nvidia.com> wrote:
> QEMU SMMUv3 currently sets the output address size (OAS) to 44 bits.
> With accelerator mode enabled, a device may use SVA, where CPU page tables
> are shared with the SMMU, requiring an OAS at least as large as the
> CPU’s output address size. A user option is added to configure this.
>
> However, the OAS value advertised by the virtual SMMU must remain
> compatible with the capabilities of the host SMMUv3. In accelerated
> mode, the host SMMU performs stage-2 translation and must be able to
> consume the intermediate physical addresses (IPA) produced by stage-1.
>
> The OAS exposed by the virtual SMMU defines the maximum IPA width that
> stage-1 translations may generate. For AArch64 implementations, the
> maximum usable IPA size on the host SMMU is determined by its own OAS.
> Check that the configured OAS does not exceed what the host SMMU
> can safely support.
>
> Tested-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
next prev parent reply other threads:[~2026-01-14 11:21 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-11 19:52 [PATCH v7 00/36] hw/arm/virt: Add support for user-creatable accelerated SMMUv3 Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 01/36] backends/iommufd: Introduce iommufd_backend_alloc_vdev Shameer Kolothum
2026-01-12 11:45 ` Cédric Le Goater
2026-01-12 14:04 ` Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 02/36] hw/arm/smmu-common: Factor out common helper functions and export Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 03/36] hw/arm/smmu-common: Make iommu ops part of SMMUState Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 04/36] hw/arm/smmuv3-accel: Introduce smmuv3 accel device Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 05/36] hw/arm/smmuv3-accel: Initialize shared system address space Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 06/36] hw/pci/pci: Move pci_init_bus_master() after adding device to bus Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 07/36] hw/pci/pci: Add optional supports_address_space() callback Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 08/36] hw/pci-bridge/pci_expander_bridge: Move TYPE_PXB_PCIE_DEV to header Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 09/36] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 10/36] hw/arm/smmuv3: Implement get_viommu_cap() callback Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 11/36] hw/arm/smmuv3-accel: Add set/unset_iommu_device callback Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 12/36] hw/arm/smmuv3: propagate smmuv3_cmdq_consume() errors to caller Shameer Kolothum
2026-01-11 19:52 ` [PATCH v7 13/36] hw/arm/smmuv3-accel: Add nested vSTE install/uninstall support Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 14/36] hw/arm/smmuv3-accel: Install SMMUv3 GBPA based hwpt Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 15/36] hw/pci/pci: Introduce a callback to retrieve the MSI doorbell GPA directly Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 16/36] hw/arm/smmuv3-accel: Implement get_msi_direct_gpa callback Shameer Kolothum
2026-01-19 13:59 ` Eric Auger
2026-01-11 19:53 ` [PATCH v7 17/36] hw/arm/virt: Set msi-gpa property Shameer Kolothum
2026-01-11 21:43 ` Mohamed Mediouni
2026-01-12 9:45 ` Shameer Kolothum
2026-01-12 10:17 ` Mohamed Mediouni
2026-01-12 15:01 ` Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 18/36] hw/arm/smmuv3-accel: Add support to issue invalidation cmd to host Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 19/36] hw/arm/smmuv3: Initialize ID registers early during realize() Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 20/36] hw/arm/smmuv3-accel: Get host SMMUv3 hw info and validate Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 21/36] hw/pci-host/gpex: Allow to generate preserve boot config DSM #5 Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 22/36] hw/arm/virt: Set PCI preserve_config for accel SMMUv3 Shameer Kolothum
2026-01-14 11:13 ` Jonathan Cameron via
2026-01-14 11:13 ` Jonathan Cameron via qemu development
2026-01-11 19:53 ` [PATCH v7 23/36] tests/qtest/bios-tables-test: Prepare for IORT revison upgrade Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 24/36] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 25/36] tests/qtest/bios-tables-test: Update IORT blobs after revision upgrade Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 26/36] hw/arm/smmuv3: Block migration when accel is enabled Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 27/36] hw/arm/smmuv3: Add accel property for SMMUv3 device Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 28/36] hw/arm/smmuv3-accel: Add a property to specify RIL support Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 29/36] hw/arm/smmuv3-accel: Add support for ATS Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 30/36] hw/arm/smmuv3-accel: Add property to specify OAS bits Shameer Kolothum
2026-01-14 11:19 ` Jonathan Cameron via [this message]
2026-01-14 11:19 ` Jonathan Cameron via qemu development
2026-01-11 19:53 ` [PATCH v7 31/36] backends/iommufd: Retrieve PASID width from iommufd_backend_get_device_info() Shameer Kolothum
2026-01-11 19:53 ` [PATCH v7 32/36] backends/iommufd: Add get_pasid_info() callback Shameer Kolothum
2026-01-14 11:23 ` Jonathan Cameron via
2026-01-14 11:23 ` Jonathan Cameron via qemu development
2026-01-19 14:06 ` Eric Auger
2026-01-11 19:53 ` [PATCH v7 33/36] hw/pci: Add helper to insert PCIe extended capability at a fixed offset Shameer Kolothum
2026-01-14 4:18 ` Zhangfei Gao
2026-01-14 10:36 ` Shameer Kolothum
2026-01-15 2:34 ` Zhangfei Gao
2026-01-19 16:01 ` Eric Auger
2026-01-19 16:03 ` Shameer Kolothum
2026-01-14 11:45 ` Jonathan Cameron via
2026-01-14 11:45 ` Jonathan Cameron via qemu development
2026-01-14 12:26 ` Shameer Kolothum
2026-01-14 12:35 ` Michael S. Tsirkin
2026-01-15 11:38 ` Jonathan Cameron via
2026-01-15 11:38 ` Jonathan Cameron via qemu development
2026-01-11 19:53 ` [PATCH v7 34/36] hw/pci: Factor out common PASID capability initialization Shameer Kolothum
2026-01-14 11:46 ` Jonathan Cameron via
2026-01-14 11:46 ` Jonathan Cameron via qemu development
2026-01-19 14:12 ` Eric Auger
2026-01-11 19:53 ` [PATCH v7 35/36] hw/vfio/pci: Synthesize PASID capability for vfio-pci devices Shameer Kolothum
2026-01-12 2:38 ` Duan, Zhenzhong
2026-01-14 11:51 ` Jonathan Cameron via
2026-01-14 11:51 ` Jonathan Cameron via qemu development
2026-01-19 16:16 ` Eric Auger
2026-01-19 17:22 ` Shameer Kolothum
2026-01-19 19:07 ` Cédric Le Goater
2026-01-11 19:53 ` [PATCH v7 36/36] hw/arm/smmuv3-accel: Make SubstreamID support configurable Shameer Kolothum
2026-01-19 8:17 ` [PATCH v7 00/36] hw/arm/virt: Add support for user-creatable accelerated SMMUv3 Zhangfei Gao
2026-01-19 8:36 ` Shameer Kolothum
2026-01-19 14:20 ` Michael S. Tsirkin
2026-01-19 16:57 ` Eric Auger
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=20260114111952.0000228a@huawei.com \
--to=qemu-arm@nongnu.org \
--cc=alex@shazbot.org \
--cc=berrange@redhat.com \
--cc=clg@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.