From: Eric Auger <eric.auger@redhat.com>
To: Jonathan Cameron <jonathan.cameron@huawei.com>,
Shameer Kolothum <skolothumtho@nvidia.com>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org,
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,
shameerkolothum@gmail.com
Subject: Re: [PATCH v4 14/27] hw/arm/smmuv3-accel: Get host SMMUv3 hw info and validate
Date: Mon, 27 Oct 2025 11:41:58 +0100 [thread overview]
Message-ID: <c7253b37-23bb-4147-8415-3c05aa7c15e4@redhat.com> (raw)
In-Reply-To: <20251001135604.00006776@huawei.com>
Hi Shameer,
On 10/1/25 2:56 PM, Jonathan Cameron wrote:
> On Mon, 29 Sep 2025 14:36:30 +0100
> Shameer Kolothum <skolothumtho@nvidia.com> wrote:
>
>> Just before the device gets attached to the SMMUv3, make sure QEMU SMMUv3
>> features are compatible with the host SMMUv3.
>>
>> Not all fields in the host SMMUv3 IDR registers are meaningful for userspace.
>> Only the following fields can be used:
>>
>> - IDR0: ST_LEVEL, TERM_MODEL, STALL_MODEL, TTENDIAN, CD2L, ASID16, TTF
>> - IDR1: SIDSIZE, SSIDSIZE
>> - IDR3: BBML, RIL
>> - IDR5: VAX, GRAN64K, GRAN16K, GRAN4K
>>
>> For now, the check is to make sure the features are in sync to enable
>> basic accelerated SMMUv3 support.
>>
>> One other related change is, move the smmuv3_init_regs() to smmu_realize()
>> so that we do have that early enough for the check mentioned above.
>>
>> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> Hi Shameer,
>
> Back to this series...
>
> Various things in the checks in here.
>
> Jonathan
>
>> ---
>> hw/arm/smmuv3-accel.c | 98 +++++++++++++++++++++++++++++++++++++++++++
>> hw/arm/smmuv3.c | 4 +-
>> 2 files changed, 100 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c
>> index 9ad8595ce2..defeddbd8c 100644
>> --- a/hw/arm/smmuv3-accel.c
>> +++ b/hw/arm/smmuv3-accel.c
>> @@ -39,6 +39,96 @@
>> #define STE1_MASK (STE1_ETS | STE1_S1STALLD | STE1_S1CSH | STE1_S1COR | \
>> STE1_S1CIR | STE1_S1DSS)
>>
>> +static bool
>> +smmuv3_accel_check_hw_compatible(SMMUv3State *s,
>> + struct iommu_hw_info_arm_smmuv3 *info,
>> + Error **errp)
>> +{
>> + uint32_t val;
>> +
>> + /*
>> + * QEMU SMMUv3 supports both linear and 2-level stream tables.
>> + */
> Single line comment would be more consistent with below and looks to be under 80 chars.
>
>> + val = FIELD_EX32(info->idr[0], IDR0, STLEVEL);
>> + if (val != FIELD_EX32(s->idr[0], IDR0, STLEVEL)) {
>> + s->idr[0] = FIELD_DP32(s->idr[0], IDR0, STLEVEL, val);
> This seems a rather odd side effect to have. Perhaps a comment on why
> in error path it make sense to change s->idr[0]?
also consider s->idr[] are not migrated. I know there is a migration
blocker set in 20/27 though. I would simply return an error here.
>
>> + error_setg(errp, "Host SUMMUv3 differs in Stream Table format");
>> + return false;
>> + }
>> +
>> + /* QEMU SMMUv3 supports only little-endian translation table walks */
>> + val = FIELD_EX32(info->idr[0], IDR0, TTENDIAN);
>> + if (!val && val > FIELD_EX32(s->idr[0], IDR0, TTENDIAN)) {
> This is a weird check. || maybe?
>
> Otherwise if !val is true, then val is not likely to be greater than anything.
> imply check info idr0 ttendian == s->idr[0] one (=2)?
>
>> + error_setg(errp, "Host SUMMUv3 doesn't support Little-endian "
>> + "translation table");
>> + return false;
>> + }
>> +
>> + /* QEMU SMMUv3 supports only AArch64 translation table format */
>> + val = FIELD_EX32(info->idr[0], IDR0, TTF);
>> + if (val < FIELD_EX32(s->idr[0], IDR0, TTF)) {
>> + error_setg(errp, "Host SUMMUv3 deosn't support Arch64 Translation "
> Spell check the messages. doesn't.
>
>> + "table format");
>> + return false;
>> + }
>> +
>> + /* QEMU SMMUv3 supports SIDSIZE 16 */
>> + val = FIELD_EX32(info->idr[1], IDR1, SIDSIZE);
>> + if (val < FIELD_EX32(s->idr[1], IDR1, SIDSIZE)) {
> Why not
> if (FIELD_EX32(info->idr[1], IDR1, SIDSIZE) <
> FIELD_EX32(s->idr[1], IDR1, SIDSIZE))
> I.e. why does the local variable make sense in cases where the value is
> only used once. To me if anything this is slightly easier to read. You could
> even align the variables so it's obvious it's comparing one field.
>
> if (FIELD_EX32(info->idr[1], IDR1, SIDSIZE) <
> FIELD_EX32(s->idr[1], IDR1, SIDSIZE))
>
>> + error_setg(errp, "Host SUMMUv3 SIDSIZE not compatible");
>> + return false;
>> + }
>> +
>> + /* QEMU SMMUv3 supports Range Invalidation by default */
>> + val = FIELD_EX32(info->idr[3], IDR3, RIL);
>> + if (val != FIELD_EX32(s->idr[3], IDR3, RIL)) {
>> + error_setg(errp, "Host SUMMUv3 deosn't support Range Invalidation");
> doesn't.
as Jonathan suggested you might avoid using the local var here too and below
>
>> + return false;
>> + }
>> +
>> + val = FIELD_EX32(info->idr[5], IDR5, GRAN4K);
>> + if (val != FIELD_EX32(s->idr[5], IDR5, GRAN4K)) {
>> + error_setg(errp, "Host SMMUv3 doesn't support 64K translation granule");
> That doesn't smell like it's checking 64K
>> + return false;
>> + }
>> + val = FIELD_EX32(info->idr[5], IDR5, GRAN16K);
>> + if (val != FIELD_EX32(s->idr[5], IDR5, GRAN16K)) {
>> + error_setg(errp, "Host SMMUv3 doesn't support 16K translation granule");
>> + return false;
>> + }
>> + val = FIELD_EX32(info->idr[5], IDR5, GRAN64K);
>> + if (val != FIELD_EX32(s->idr[5], IDR5, GRAN64K)) {
>> + error_setg(errp, "Host SMMUv3 doesn't support 16K translation granule");
> Nor is this one seem likely to be checking 16K.
>> + return false;
>> + }
>> + return true;
>> +}
>> +
>> +static bool
>> +smmuv3_accel_hw_compatible(SMMUv3State *s, HostIOMMUDeviceIOMMUFD *idev,
>> + Error **errp)
>> +{
>> + struct iommu_hw_info_arm_smmuv3 info;
>> + uint32_t data_type;
>> + uint64_t caps;
>> +
>> + if (!iommufd_backend_get_device_info(idev->iommufd, idev->devid, &data_type,
>> + &info, sizeof(info), &caps, errp)) {
>> + return false;
>> + }
>> +
>> + if (data_type != IOMMU_HW_INFO_TYPE_ARM_SMMUV3) {
>> + error_setg(errp, "Wrong data type (%d) for Host SMMUv3 device info",
>> + data_type);
> Alignment looks off.
>
>> + return false;
>> + }
>> +
>> + if (!smmuv3_accel_check_hw_compatible(s, &info, errp)) {
>> + return false;
>> + }
>> + return true;
return smmuv3_accel_check_hw_compatible(s, &info, errp)
>> +}
>> +
>
Eric
next prev parent reply other threads:[~2025-10-27 10:42 UTC|newest]
Thread overview: 131+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-29 13:36 [PATCH v4 00/27] hw/arm/virt: Add support for user-creatable accelerated SMMUv3 Shameer Kolothum
2025-09-29 13:36 ` [PATCH v4 01/27] backends/iommufd: Introduce iommufd_backend_alloc_viommu Shameer Kolothum
2025-09-29 15:35 ` Jonathan Cameron via
2025-10-17 12:21 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 02/27] backends/iommufd: Introduce iommufd_vdev_alloc Shameer Kolothum
2025-09-29 15:40 ` Jonathan Cameron via
2025-09-29 17:52 ` Nicolin Chen
2025-09-30 8:14 ` Shameer Kolothum
2025-09-29 13:36 ` [PATCH v4 03/27] hw/arm/smmu-common: Factor out common helper functions and export Shameer Kolothum
2025-09-29 15:43 ` Jonathan Cameron via
2025-09-29 13:36 ` [PATCH v4 04/27] hw/arm/smmu-common:Make iommu ops part of SMMUState Shameer Kolothum
2025-09-29 15:45 ` Jonathan Cameron via
2025-09-29 21:53 ` Nicolin Chen via
2025-10-01 16:11 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 05/27] hw/arm/smmuv3-accel: Introduce smmuv3 accel device Shameer Kolothum
2025-09-29 15:53 ` Jonathan Cameron via
2025-09-29 22:24 ` Nicolin Chen
2025-10-01 16:25 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 06/27] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd Shameer Kolothum
2025-09-29 16:08 ` Jonathan Cameron via
2025-09-30 8:03 ` Shameer Kolothum
2025-10-01 16:38 ` Eric Auger
2025-10-02 8:16 ` Shameer Kolothum
2025-09-30 0:11 ` Nicolin Chen
2025-10-02 7:29 ` Shameer Kolothum
2025-10-01 17:32 ` Eric Auger
2025-10-02 9:30 ` Shameer Kolothum
2025-10-17 12:47 ` Eric Auger
2025-10-17 13:15 ` Shameer Kolothum
2025-10-17 17:19 ` Eric Auger
2025-10-20 16:31 ` Eric Auger
2025-10-20 18:25 ` Nicolin Chen
2025-10-20 18:59 ` Shameer Kolothum
2025-10-21 15:28 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 07/27] hw/arm/smmuv3: Implement get_viommu_cap() callback Shameer Kolothum
2025-09-29 16:13 ` Jonathan Cameron via
2025-10-01 17:36 ` Eric Auger
2025-10-02 9:38 ` Shameer Kolothum
2025-10-02 12:31 ` Eric Auger
2025-10-02 9:39 ` Jonathan Cameron via
2025-09-29 13:36 ` [PATCH v4 08/27] hw/arm/smmuv3-accel: Add set/unset_iommu_device callback Shameer Kolothum
2025-09-29 16:25 ` Jonathan Cameron via
2025-09-30 8:13 ` Shameer Kolothum
2025-10-02 6:52 ` Eric Auger
2025-10-02 11:34 ` Shameer Kolothum
2025-10-02 16:44 ` Nicolin Chen
2025-10-02 18:35 ` Jason Gunthorpe
2025-10-17 12:06 ` Eric Auger
2025-10-27 11:56 ` Shameer Kolothum
2025-10-27 14:10 ` Eric Auger
2025-10-17 12:23 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 09/27] hw/arm/smmuv3-accel: Support nested STE install/uninstall support Shameer Kolothum
2025-09-29 16:41 ` Jonathan Cameron via
2025-10-02 10:04 ` Eric Auger
2025-10-02 12:08 ` Shameer Kolothum
2025-10-02 12:27 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 10/27] hw/arm/smmuv3-accel: Allocate a vDEVICE object for device Shameer Kolothum
2025-09-29 16:42 ` Jonathan Cameron via
2025-10-17 13:08 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 11/27] hw/pci/pci: Introduce optional get_msi_address_space() callback Shameer Kolothum
2025-09-29 16:48 ` Jonathan Cameron via
2025-10-16 22:30 ` Nicolin Chen
2025-10-20 16:14 ` Eric Auger
2025-10-20 18:00 ` Nicolin Chen
2025-10-21 16:26 ` Eric Auger
2025-10-21 18:56 ` Nicolin Chen
2025-10-22 16:25 ` Eric Auger
2025-10-22 16:56 ` Shameer Kolothum
2025-10-20 16:21 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 12/27] hw/arm/smmuv3-accel: Make use of " Shameer Kolothum
2025-09-29 16:51 ` Jonathan Cameron via
2025-10-02 7:33 ` Shameer Kolothum
2025-10-16 23:28 ` Nicolin Chen
2025-10-20 16:43 ` Eric Auger
2025-10-21 8:15 ` Shameer Kolothum
2025-10-21 16:16 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 13/27] hw/arm/smmuv3-accel: Add support to issue invalidation cmd to host Shameer Kolothum
2025-09-29 16:53 ` Jonathan Cameron via
2025-10-16 22:59 ` Nicolin Chen via
2025-10-27 10:13 ` Eric Auger
2025-10-27 12:20 ` Shameer Kolothum
2025-10-27 14:05 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 14/27] hw/arm/smmuv3-accel: Get host SMMUv3 hw info and validate Shameer Kolothum
2025-10-01 12:56 ` Jonathan Cameron via
2025-10-02 7:37 ` Shameer Kolothum
2025-10-02 9:54 ` Jonathan Cameron via
2025-10-27 10:41 ` Eric Auger [this message]
2025-10-27 12:23 ` Shameer Kolothum
2025-10-27 10:46 ` Eric Auger
2025-10-27 12:24 ` Shameer Kolothum
2025-09-29 13:36 ` [PATCH v4 15/27] acpi/gpex: Fix PCI Express Slot Information function 0 returned value Shameer Kolothum
2025-10-01 12:59 ` Jonathan Cameron via
2025-10-02 7:39 ` Shameer Kolothum
2025-10-21 15:32 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 16/27] hw/pci-host/gpex: Allow to generate preserve boot config DSM #5 Shameer Kolothum
2025-10-01 13:05 ` Jonathan Cameron via
2025-10-27 11:14 ` Eric Auger
2025-10-27 11:10 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 17/27] hw/arm/virt: Set PCI preserve_config for accel SMMUv3 Shameer Kolothum
2025-10-01 13:06 ` Jonathan Cameron via
2025-10-27 11:21 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 18/27] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding Shameer Kolothum
2025-10-01 13:30 ` Jonathan Cameron via
2025-09-29 13:36 ` [PATCH v4 19/27] hw/arm/smmuv3-accel: Install S1 bypass hwpt on reset Shameer Kolothum
2025-10-01 13:32 ` Jonathan Cameron via
2025-10-16 23:19 ` Nicolin Chen
2025-10-20 14:22 ` Shameer Kolothum
2025-10-27 14:22 ` Eric Auger
2025-09-29 13:36 ` [PATCH v4 20/27] hw/arm/smmuv3: Add accel property for SMMUv3 device Shameer Kolothum
2025-10-16 21:48 ` Nicolin Chen
2025-09-29 13:36 ` [PATCH v4 21/27] hw/arm/smmuv3-accel: Add a property to specify RIL support Shameer Kolothum
2025-10-01 13:39 ` Jonathan Cameron via
2025-10-17 8:48 ` Zhangfei Gao
2025-10-17 9:40 ` Shameer Kolothum
2025-10-17 14:05 ` Zhangfei Gao
2025-09-29 13:36 ` [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS Shameer Kolothum
2025-10-01 13:43 ` Jonathan Cameron via
2025-09-29 13:36 ` [PATCH v4 23/27] hw/arm/smmuv3-accel: Add property to specify OAS bits Shameer Kolothum
2025-10-01 13:46 ` Jonathan Cameron via
2025-09-29 13:36 ` [PATCH v4 24/27] backends/iommufd: Retrieve PASID width from iommufd_backend_get_device_info() Shameer Kolothum
2025-10-01 13:50 ` Jonathan Cameron via
2025-09-29 13:36 ` [PATCH v4 25/27] backends/iommufd: Add a callback helper to retrieve PASID support Shameer Kolothum
2025-10-01 13:52 ` Jonathan Cameron via
2025-09-29 13:36 ` [PATCH v4 26/27] vfio: Synthesize vPASID capability to VM Shameer Kolothum
2025-10-01 13:58 ` Jonathan Cameron via
2025-10-02 8:03 ` Shameer Kolothum
2025-10-02 9:58 ` Jonathan Cameron via
2025-09-29 13:36 ` [PATCH v4 27/27] hw.arm/smmuv3: Add support for PASID enable Shameer Kolothum
2025-10-01 14:01 ` Jonathan Cameron via
2025-10-17 6:25 ` [PATCH v4 00/27] hw/arm/virt: Add support for user-creatable accelerated SMMUv3 Zhangfei Gao
2025-10-17 9:43 ` 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=c7253b37-23bb-4147-8415-3c05aa7c15e4@redhat.com \
--to=eric.auger@redhat.com \
--cc=berrange@redhat.com \
--cc=ddutile@redhat.com \
--cc=jgg@nvidia.com \
--cc=jiangkunkun@huawei.com \
--cc=jonathan.cameron@huawei.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=shameerkolothum@gmail.com \
--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 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).