Hi Cédric,
> -----Original Message-----
> From: Cédric Le Goater <[email protected]>
> Sent: 11 December 2025 12:55
> To: Shameer Kolothum <[email protected]>; qemu-
> [email protected]; [email protected]
> Cc: [email protected]; [email protected]; Jason Gunthorpe
> <[email protected]>; Nicolin Chen <[email protected]>;
> [email protected]; [email protected]; Nathan Chen
> <[email protected]>; Matt Ochs <[email protected]>;
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> Krishnakant Jaju <[email protected]>
> Subject: Re: [PATCH v6 05/33] hw/arm/smmuv3-accel: Introduce smmuv3
> accel device
>
> External email: Use caution opening links or attachments
>
>
> On 11/20/25 14:21, Shameer Kolothum wrote:
> > Set up dedicated PCIIOMMUOps for the accel SMMUv3, since it will need
> > different callback handling in upcoming patches. This also adds a
> > CONFIG_ARM_SMMUV3_ACCEL build option so the feature can be disabled
> > at compile time. Because we now include CONFIG_DEVICES in the header to
> > check for ARM_SMMUV3_ACCEL, the meson file entry for smmuv3.c needs
> to
> > be changed to arm_ss.add.
> >
> > The “accel” property isn’t user visible yet and it will be introduced in
> > a later patch once all the supporting pieces are ready.
> >
> > Signed-off-by: Shameer Kolothum
> <[email protected]>
> > Reviewed-by: Nicolin Chen <[email protected]>
> > Reviewed-by: Jonathan Cameron <[email protected]>
> > Reviewed-by: Eric Auger <[email protected]>
> > Tested-by: Zhangfei Gao <[email protected]>
> > Signed-off-by: Shameer Kolothum <[email protected]>
> > ---
> > hw/arm/Kconfig | 5 ++++
> > hw/arm/meson.build | 3 ++-
> > hw/arm/smmuv3-accel.c | 59
> +++++++++++++++++++++++++++++++++++++++++
> > hw/arm/smmuv3-accel.h | 27 +++++++++++++++++++
> > hw/arm/smmuv3.c | 5 ++++
> > include/hw/arm/smmuv3.h | 3 +++
> > 6 files changed, 101 insertions(+), 1 deletion(-)
> > create mode 100644 hw/arm/smmuv3-accel.c
> > create mode 100644 hw/arm/smmuv3-accel.h
> >
> > diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> > index 0cdeb60f1f..702b79a02b 100644
> > --- a/hw/arm/Kconfig
> > +++ b/hw/arm/Kconfig
> > @@ -12,6 +12,7 @@ config ARM_VIRT
> > select ARM_GIC
> > select ACPI
> > select ARM_SMMUV3
> > + select ARM_SMMUV3_ACCEL
> > select GPIO_KEY
> > select DEVICE_TREE
> > select FW_CFG_DMA
> > @@ -629,6 +630,10 @@ config FSL_IMX8MP_EVK
> > config ARM_SMMUV3
> > bool
> >
> > +config ARM_SMMUV3_ACCEL
> > + bool
> > + depends on ARM_SMMUV3 && IOMMUFD
> > +
> > config FSL_IMX6UL
> > bool
> > default y
> > diff --git a/hw/arm/meson.build b/hw/arm/meson.build
> > index aeaf654790..c250487e64 100644
> > --- a/hw/arm/meson.build
> > +++ b/hw/arm/meson.build
> > @@ -84,7 +84,8 @@ arm_common_ss.add(when: 'CONFIG_ARMSSE',
> if_true: files('armsse.c'))
> > arm_common_ss.add(when: 'CONFIG_FSL_IMX7', if_true: files('fsl-imx7.c',
> 'mcimx7d-sabre.c'))
> > arm_common_ss.add(when: 'CONFIG_FSL_IMX8MP', if_true: files('fsl-
> imx8mp.c'))
> > arm_common_ss.add(when: 'CONFIG_FSL_IMX8MP_EVK', if_true:
> files('imx8mp-evk.c'))
> > -arm_common_ss.add(when: 'CONFIG_ARM_SMMUV3', if_true:
> files('smmuv3.c'))
> > +arm_ss.add(when: 'CONFIG_ARM_SMMUV3', if_true: files('smmuv3.c'))
> > +arm_ss.add(when: 'CONFIG_ARM_SMMUV3_ACCEL', if_true:
> files('smmuv3-accel.c'))
> > arm_common_ss.add(when: 'CONFIG_FSL_IMX6UL', if_true: files('fsl-
> imx6ul.c', 'mcimx6ul-evk.c'))
> > arm_common_ss.add(when: 'CONFIG_NRF51_SOC', if_true:
> files('nrf51_soc.c'))
> > arm_common_ss.add(when: 'CONFIG_XEN', if_true: files(
> > diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c
> > new file mode 100644
> > index 0000000000..99ef0db8c4
> > --- /dev/null
> > +++ b/hw/arm/smmuv3-accel.c
> > @@ -0,0 +1,59 @@
> > +/*
> > + * Copyright (c) 2025 Huawei Technologies R & D (UK) Ltd
> > + * Copyright (C) 2025 NVIDIA
> > + * Written by Nicolin Chen, Shameer Kolothum
> > + *
> > + * SPDX-License-Identifier: GPL-2.0-or-later
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +
> > +#include "hw/arm/smmuv3.h"
> > +#include "smmuv3-accel.h"
> > +
> > +static SMMUv3AccelDevice *smmuv3_accel_get_dev(SMMUState *bs,
> SMMUPciBus *sbus,
> > + PCIBus *bus, int devfn)
> > +{
> > + SMMUDevice *sdev = sbus->pbdev[devfn];
> > + SMMUv3AccelDevice *accel_dev;
> > +
> > + if (sdev) {
> > + return container_of(sdev, SMMUv3AccelDevice, sdev);
> > + }
> > +
> > + accel_dev = g_new0(SMMUv3AccelDevice, 1);
>
> oh. This is not a QOM object :/
Right.
>
> > + sdev = &accel_dev->sdev;
> > +
> > + sbus->pbdev[devfn] = sdev;
> > + smmu_init_sdev(bs, sdev, bus, devfn);
> > + return accel_dev;
> > +}
> > +
> > +/*
> > + * Find or add an address space for the given PCI device.
> > + *
> > + * If a device matching @bus and @devfn already exists, return its
> > + * corresponding address space. Otherwise, create a new device entry
> > + * and initialize address space for it.
> > + */
> > +static AddressSpace *smmuv3_accel_find_add_as(PCIBus *bus, void
> *opaque,
> > + int devfn)
> > +{
> > + SMMUState *bs = opaque;
> > + SMMUPciBus *sbus = smmu_get_sbus(bs, bus);
> > + SMMUv3AccelDevice *accel_dev = smmuv3_accel_get_dev(bs, sbus,
> bus, devfn);
> > + SMMUDevice *sdev = &accel_dev->sdev;
> > +
> > + return &sdev->as;
> > +}
> > +
> > +static const PCIIOMMUOps smmuv3_accel_ops = {
> > + .get_address_space = smmuv3_accel_find_add_as,
> > +};
> > +
> > +void smmuv3_accel_init(SMMUv3State *s)
> > +{
> > + SMMUState *bs = ARM_SMMU(s);
> > +
> > + bs->iommu_ops = &smmuv3_accel_ops;
>
> again, I think this should be a sSMMUv3Class attribute.
See below.
>
> > +}
> > diff --git a/hw/arm/smmuv3-accel.h b/hw/arm/smmuv3-accel.h
> > new file mode 100644
> > index 0000000000..0dc6b00d35
> > --- /dev/null
> > +++ b/hw/arm/smmuv3-accel.h
> > @@ -0,0 +1,27 @@
> > +/*
> > + * Copyright (c) 2025 Huawei Technologies R & D (UK) Ltd
> > + * Copyright (C) 2025 NVIDIA
> > + * Written by Nicolin Chen, Shameer Kolothum
> > + *
> > + * SPDX-License-Identifier: GPL-2.0-or-later
> > + */
> > +
> > +#ifndef HW_ARM_SMMUV3_ACCEL_H
> > +#define HW_ARM_SMMUV3_ACCEL_H
> > +
> > +#include "hw/arm/smmu-common.h"
> > +#include CONFIG_DEVICES
> > +
> > +typedef struct SMMUv3AccelDevice {
> > + SMMUDevice sdev;
> > +} SMMUv3AccelDevice;
> > +
> > +#ifdef CONFIG_ARM_SMMUV3_ACCEL
> > +void smmuv3_accel_init(SMMUv3State *s);
> > +#else
> > +static inline void smmuv3_accel_init(SMMUv3State *s)
> > +{
> > +}
> > +#endif
> > +
> > +#endif /* HW_ARM_SMMUV3_ACCEL_H */
> > diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> > index bcf8af8dc7..ef991cb7d8 100644
> > --- a/hw/arm/smmuv3.c
> > +++ b/hw/arm/smmuv3.c
> > @@ -32,6 +32,7 @@
> > #include "qapi/error.h"
> >
> > #include "hw/arm/smmuv3.h"
> > +#include "smmuv3-accel.h"
> > #include "smmuv3-internal.h"
> > #include "smmu-internal.h"
> >
> > @@ -1882,6 +1883,10 @@ static void smmu_realize(DeviceState *d, Error
> **errp)
> > SysBusDevice *dev = SYS_BUS_DEVICE(d);
> > Error *local_err = NULL;
> >
> > + if (s->accel) {
> > + smmuv3_accel_init(s);
> > + }
> > +
> > c->parent_realize(d, &local_err);
> > if (local_err) {
> > error_propagate(errp, local_err);
> > diff --git a/include/hw/arm/smmuv3.h b/include/hw/arm/smmuv3.h
> > index d183a62766..bb7076286b 100644
> > --- a/include/hw/arm/smmuv3.h
> > +++ b/include/hw/arm/smmuv3.h
> > @@ -63,6 +63,9 @@ struct SMMUv3State {
> > qemu_irq irq[4];
> > QemuMutex mutex;
> > char *stage;
> > +
> > + /* SMMU has HW accelerator support for nested S1 + s2 */
> > + bool accel;
>
> Have you considered modeling with a QOM object instead ?
A bit of history on this:
The SMMUv3 accel support was introduced first as a separate device,
-device arm-smmuv3-accel
https://lore.kernel.org/qemu-devel/[email protected]/
However, the general consensus at that time was that we should instead
model it on the -device arm-smmuv3 itself, with an added "accel" property.
Eric had also suggested making use of something similar to the
TYPE_VFIO_IOMMU_IOMMUFD / LEGACY classes for selecting the iommu_ops.
https://lore.kernel.org/qemu-devel/[email protected]/
In RFCv3, I did introduce a TYPE_ARM_SMMUV3_ACCEL object class, but we
later found that it wasn’t doing much beyond helping to retrieve the iommu_ops
based on the object type, so decided to drop it.
https://lore.kernel.org/qemu-devel/[email protected]/
From your feedback, I understand that you would like to revisit that approach
again. Just to make sure I get this right, is the SMMUv3AccelClass you have in
mind meant to be an abstract object, like HOST_IOMMU_DEVICE, or are
you suggesting another child device object?
Please let me know if there is an example/precedent, I can look at for a similar
object model in QEMU.
Thanks,
Shameer
