Allow cold-plug smmuv3-accel to virt If the machine wide smmuv3
is not specified.
No FDT support is added for now.
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
hw/arm/virt.c | 12 ++++++++++++
hw/core/sysbus-fdt.c | 1 +
include/hw/arm/virt.h | 1 +
3 files changed, 14 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 4a5a9666e9..84a323da55 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -73,6 +73,7 @@
#include "qobject/qlist.h"
#include "standard-headers/linux/input.h"
#include "hw/arm/smmuv3.h"
+#include "hw/arm/smmuv3-accel.h"
#include "hw/acpi/acpi.h"
#include "target/arm/cpu-qom.h"
#include "target/arm/internals.h"
@@ -2911,6 +2912,16 @@ static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
platform_bus_link_device(PLATFORM_BUS_DEVICE(vms->platform_bus_dev),
SYS_BUS_DEVICE(dev));
}
+ if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3_ACCEL)) {
+ if (vms->iommu == VIRT_IOMMU_SMMUV3) {
+ error_setg(errp,
+ "iommu=smmuv3 is already specified. can't create smmuv3-accel dev");
+ return;
+ }
+ if (vms->iommu != VIRT_IOMMU_SMMUV3_ACCEL) {
+ vms->iommu = VIRT_IOMMU_SMMUV3_ACCEL;
+ }
+ }
}
if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
@@ -3120,6 +3131,7 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE);
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_PLATFORM);
+ machine_class_allow_dynamic_sysbus_dev(mc, TYPE_ARM_SMMUV3_ACCEL);
#ifdef CONFIG_TPM
machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
#endif
diff --git a/hw/core/sysbus-fdt.c b/hw/core/sysbus-fdt.c
index 774c0aed41..c8502ad830 100644
--- a/hw/core/sysbus-fdt.c
+++ b/hw/core/sysbus-fdt.c
@@ -489,6 +489,7 @@ static const BindingEntry bindings[] = {
#ifdef CONFIG_LINUX
TYPE_BINDING(TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node),
TYPE_BINDING(TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node),
+ TYPE_BINDING("arm-smmuv3-accel", no_fdt_node),
VFIO_PLATFORM_BINDING("amd,xgbe-seattle-v1a", add_amd_xgbe_fdt_node),
#endif
#ifdef CONFIG_TPM
diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
index c8e94e6aed..849d1cd5b5 100644
--- a/include/hw/arm/virt.h
+++ b/include/hw/arm/virt.h
@@ -92,6 +92,7 @@ enum {
typedef enum VirtIOMMUType {
VIRT_IOMMU_NONE,
VIRT_IOMMU_SMMUV3,
+ VIRT_IOMMU_SMMUV3_ACCEL,
VIRT_IOMMU_VIRTIO,
} VirtIOMMUType;
--
2.34.1
Doesn't this commit become moot, if accel becomes an smmuv3 option vs separate device object altogether,
dynamically added if a pdev is attached to a host SMMUv3 that has accel feature(s)?
Blocking w/virtio-iommu falls under the same situation mentioned in 03/20 wrt mixing emulated & physical devices on the same smmuv3.
- Don
On 3/11/25 10:10 AM, Shameer Kolothum wrote:
> Allow cold-plug smmuv3-accel to virt If the machine wide smmuv3
> is not specified.
>
> No FDT support is added for now.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> hw/arm/virt.c | 12 ++++++++++++
> hw/core/sysbus-fdt.c | 1 +
> include/hw/arm/virt.h | 1 +
> 3 files changed, 14 insertions(+)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 4a5a9666e9..84a323da55 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -73,6 +73,7 @@
> #include "qobject/qlist.h"
> #include "standard-headers/linux/input.h"
> #include "hw/arm/smmuv3.h"
> +#include "hw/arm/smmuv3-accel.h"
> #include "hw/acpi/acpi.h"
> #include "target/arm/cpu-qom.h"
> #include "target/arm/internals.h"
> @@ -2911,6 +2912,16 @@ static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
> platform_bus_link_device(PLATFORM_BUS_DEVICE(vms->platform_bus_dev),
> SYS_BUS_DEVICE(dev));
> }
> + if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3_ACCEL)) {
> + if (vms->iommu == VIRT_IOMMU_SMMUV3) {
> + error_setg(errp,
> + "iommu=smmuv3 is already specified. can't create smmuv3-accel dev");
> + return;
> + }
> + if (vms->iommu != VIRT_IOMMU_SMMUV3_ACCEL) {
> + vms->iommu = VIRT_IOMMU_SMMUV3_ACCEL;
> + }
> + }
> }
>
> if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
> @@ -3120,6 +3131,7 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE);
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_PLATFORM);
> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_ARM_SMMUV3_ACCEL);
> #ifdef CONFIG_TPM
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
> #endif
> diff --git a/hw/core/sysbus-fdt.c b/hw/core/sysbus-fdt.c
> index 774c0aed41..c8502ad830 100644
> --- a/hw/core/sysbus-fdt.c
> +++ b/hw/core/sysbus-fdt.c
> @@ -489,6 +489,7 @@ static const BindingEntry bindings[] = {
> #ifdef CONFIG_LINUX
> TYPE_BINDING(TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node),
> TYPE_BINDING(TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node),
> + TYPE_BINDING("arm-smmuv3-accel", no_fdt_node),
> VFIO_PLATFORM_BINDING("amd,xgbe-seattle-v1a", add_amd_xgbe_fdt_node),
> #endif
> #ifdef CONFIG_TPM
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index c8e94e6aed..849d1cd5b5 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -92,6 +92,7 @@ enum {
> typedef enum VirtIOMMUType {
> VIRT_IOMMU_NONE,
> VIRT_IOMMU_SMMUV3,
> + VIRT_IOMMU_SMMUV3_ACCEL,
> VIRT_IOMMU_VIRTIO,
> } VirtIOMMUType;
>
> -----Original Message----- > From: Donald Dutile <ddutile@redhat.com> > Sent: Tuesday, March 18, 2025 10:50 PM > To: Shameerali Kolothum Thodi > <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org; > qemu-devel@nongnu.org > Cc: eric.auger@redhat.com; peter.maydell@linaro.org; jgg@nvidia.com; > nicolinc@nvidia.com; berrange@redhat.com; nathanc@nvidia.com; > mochs@nvidia.com; smostafa@google.com; Linuxarm > <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>; > jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron > <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org > Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3- > accel > > > Doesn't this commit become moot, if accel becomes an smmuv3 option vs > separate device object altogether, dynamically added if a pdev is attached > to a host SMMUv3 that has accel feature(s)? > > Blocking w/virtio-iommu falls under the same situation mentioned in 03/20 > wrt mixing emulated & physical devices on the same smmuv3. Yes, this patch might change once we move to "-device smmuv3, accel=on" version. Thanks, Shameer
Hi Shameer,
On 3/11/25 3:10 PM, Shameer Kolothum wrote:
> Allow cold-plug smmuv3-accel to virt If the machine wide smmuv3
> is not specified.
>
> No FDT support is added for now.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> hw/arm/virt.c | 12 ++++++++++++
> hw/core/sysbus-fdt.c | 1 +
> include/hw/arm/virt.h | 1 +
> 3 files changed, 14 insertions(+)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 4a5a9666e9..84a323da55 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -73,6 +73,7 @@
> #include "qobject/qlist.h"
> #include "standard-headers/linux/input.h"
> #include "hw/arm/smmuv3.h"
> +#include "hw/arm/smmuv3-accel.h"
> #include "hw/acpi/acpi.h"
> #include "target/arm/cpu-qom.h"
> #include "target/arm/internals.h"
> @@ -2911,6 +2912,16 @@ static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
> platform_bus_link_device(PLATFORM_BUS_DEVICE(vms->platform_bus_dev),
> SYS_BUS_DEVICE(dev));
> }
> + if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3_ACCEL)) {
> + if (vms->iommu == VIRT_IOMMU_SMMUV3) {
maybe just check whether it is != VIRT_IOMMU_NONE?
> + error_setg(errp,
> + "iommu=smmuv3 is already specified. can't create smmuv3-accel dev");
I would clearly state "iommu=smmuv3 virt machine option is alreadt set"
and use an error hint to say both are not compatible.
> + return;
> + }
> + if (vms->iommu != VIRT_IOMMU_SMMUV3_ACCEL) {
> + vms->iommu = VIRT_IOMMU_SMMUV3_ACCEL;
I know there were quite a lot of dicussions on the 1st multi
instantiation series related to the way we instanatiate that device and
maybe I missed some blockers but why wouldn't we allow the instantiation
of the legacy smmu device with -device too. I think this would be
simpler for libvirt and we would somehow deprecate the machine option
method? would that make a problem if you were to use -device smmu,accel
or something alike?
> + }
> + }
> }
>
> if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
> @@ -3120,6 +3131,7 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_RAMFB_DEVICE);
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_PLATFORM);
> + machine_class_allow_dynamic_sysbus_dev(mc, TYPE_ARM_SMMUV3_ACCEL);
> #ifdef CONFIG_TPM
> machine_class_allow_dynamic_sysbus_dev(mc, TYPE_TPM_TIS_SYSBUS);
> #endif
> diff --git a/hw/core/sysbus-fdt.c b/hw/core/sysbus-fdt.c
> index 774c0aed41..c8502ad830 100644
> --- a/hw/core/sysbus-fdt.c
> +++ b/hw/core/sysbus-fdt.c
> @@ -489,6 +489,7 @@ static const BindingEntry bindings[] = {
> #ifdef CONFIG_LINUX
> TYPE_BINDING(TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node),
> TYPE_BINDING(TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node),
> + TYPE_BINDING("arm-smmuv3-accel", no_fdt_node),
use the define instead.
to me this patch should be moved at the end of the series when the
device is fully functional.
> VFIO_PLATFORM_BINDING("amd,xgbe-seattle-v1a", add_amd_xgbe_fdt_node),
> #endif
> #ifdef CONFIG_TPM
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index c8e94e6aed..849d1cd5b5 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -92,6 +92,7 @@ enum {
> typedef enum VirtIOMMUType {
> VIRT_IOMMU_NONE,
> VIRT_IOMMU_SMMUV3,
> + VIRT_IOMMU_SMMUV3_ACCEL,
> VIRT_IOMMU_VIRTIO,
> } VirtIOMMUType;
>
Thanks
Eric
Hi Eric,
> -----Original Message-----
> From: qemu-devel-
> bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org <qemu-
> devel-bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org> On
> Behalf Of Eric Auger
> Sent: Wednesday, March 12, 2025 3:36 PM
> To: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> qemu-devel@nongnu.org
> Cc: 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; Linuxarm
> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>;
> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron
> <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org
> Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3-
> accel
>
> Hi Shameer,
>
>
> On 3/11/25 3:10 PM, Shameer Kolothum wrote:
> > Allow cold-plug smmuv3-accel to virt If the machine wide smmuv3
> > is not specified.
> >
> > No FDT support is added for now.
> >
> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> > ---
> > hw/arm/virt.c | 12 ++++++++++++
> > hw/core/sysbus-fdt.c | 1 +
> > include/hw/arm/virt.h | 1 +
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index 4a5a9666e9..84a323da55 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -73,6 +73,7 @@
> > #include "qobject/qlist.h"
> > #include "standard-headers/linux/input.h"
> > #include "hw/arm/smmuv3.h"
> > +#include "hw/arm/smmuv3-accel.h"
> > #include "hw/acpi/acpi.h"
> > #include "target/arm/cpu-qom.h"
> > #include "target/arm/internals.h"
> > @@ -2911,6 +2912,16 @@ static void
> virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
> > platform_bus_link_device(PLATFORM_BUS_DEVICE(vms-
> >platform_bus_dev),
> > SYS_BUS_DEVICE(dev));
> > }
> > + if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3_ACCEL))
> {
> > + if (vms->iommu == VIRT_IOMMU_SMMUV3) {
> maybe just check whether it is != VIRT_IOMMU_NONE?
> > + error_setg(errp,
> > + "iommu=smmuv3 is already specified. can't create
> smmuv3-accel dev");
> I would clearly state "iommu=smmuv3 virt machine option is alreadt set"
> and use an error hint to say both are not compatible.
> > + return;
> > + }
> > + if (vms->iommu != VIRT_IOMMU_SMMUV3_ACCEL) {
> > + vms->iommu = VIRT_IOMMU_SMMUV3_ACCEL;
>
> I know there were quite a lot of dicussions on the 1st multi
> instantiation series related to the way we instanatiate that device and
> maybe I missed some blockers but why wouldn't we allow the instantiation
> of the legacy smmu device with -device too. I think this would be
> simpler for libvirt and we would somehow deprecate the machine option
> method? would that make a problem if you were to use -device smmu,accel
> or something alike?
Thanks for taking a look. I am just jumping on this one for now. Yes, there
were discussions around that. But I was not sure we concluded on deprecating
the machine option. So if I get you correctly the idea is,
if we have,
-device smmuv3 it will instantiate the current machine wide smmuv3 and for
-device smmuv3,accel this device?
Thanks,
Shameer
Hi Shameer,
On 3/12/25 4:46 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -----Original Message-----
>> From: qemu-devel-
>> bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org <qemu-
>> devel-bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org> On
>> Behalf Of Eric Auger
>> Sent: Wednesday, March 12, 2025 3:36 PM
>> To: Shameerali Kolothum Thodi
>> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
>> qemu-devel@nongnu.org
>> Cc: 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; Linuxarm
>> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>;
>> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron
>> <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org
>> Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3-
>> accel
>>
>> Hi Shameer,
>>
>>
>> On 3/11/25 3:10 PM, Shameer Kolothum wrote:
>>> Allow cold-plug smmuv3-accel to virt If the machine wide smmuv3
>>> is not specified.
>>>
>>> No FDT support is added for now.
>>>
>>> Signed-off-by: Shameer Kolothum
>> <shameerali.kolothum.thodi@huawei.com>
>>> ---
>>> hw/arm/virt.c | 12 ++++++++++++
>>> hw/core/sysbus-fdt.c | 1 +
>>> include/hw/arm/virt.h | 1 +
>>> 3 files changed, 14 insertions(+)
>>>
>>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>>> index 4a5a9666e9..84a323da55 100644
>>> --- a/hw/arm/virt.c
>>> +++ b/hw/arm/virt.c
>>> @@ -73,6 +73,7 @@
>>> #include "qobject/qlist.h"
>>> #include "standard-headers/linux/input.h"
>>> #include "hw/arm/smmuv3.h"
>>> +#include "hw/arm/smmuv3-accel.h"
>>> #include "hw/acpi/acpi.h"
>>> #include "target/arm/cpu-qom.h"
>>> #include "target/arm/internals.h"
>>> @@ -2911,6 +2912,16 @@ static void
>> virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
>>> platform_bus_link_device(PLATFORM_BUS_DEVICE(vms-
>>> platform_bus_dev),
>>> SYS_BUS_DEVICE(dev));
>>> }
>>> + if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3_ACCEL))
>> {
>>> + if (vms->iommu == VIRT_IOMMU_SMMUV3) {
>> maybe just check whether it is != VIRT_IOMMU_NONE?
>>> + error_setg(errp,
>>> + "iommu=smmuv3 is already specified. can't create
>> smmuv3-accel dev");
>> I would clearly state "iommu=smmuv3 virt machine option is alreadt set"
>> and use an error hint to say both are not compatible.
>>> + return;
>>> + }
>>> + if (vms->iommu != VIRT_IOMMU_SMMUV3_ACCEL) {
>>> + vms->iommu = VIRT_IOMMU_SMMUV3_ACCEL;
>> I know there were quite a lot of dicussions on the 1st multi
>> instantiation series related to the way we instanatiate that device and
>> maybe I missed some blockers but why wouldn't we allow the instantiation
>> of the legacy smmu device with -device too. I think this would be
>> simpler for libvirt and we would somehow deprecate the machine option
>> method? would that make a problem if you were to use -device smmu,accel
>> or something alike?
> Thanks for taking a look. I am just jumping on this one for now. Yes, there
> were discussions around that. But I was not sure we concluded on deprecating
> the machine option. So if I get you correctly the idea is,
>
> if we have,
> -device smmuv3 it will instantiate the current machine wide smmuv3 and for
> -device smmuv3,accel this device?
yes that would be my preference.
Eric
>
> Thanks,
> Shameer
> -----Original Message-----
> From: qemu-devel-
> bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org <qemu-
> devel-bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org> On
> Behalf Of Eric Auger
> Sent: Wednesday, March 12, 2025 4:13 PM
> To: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> qemu-devel@nongnu.org
> Cc: 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; Linuxarm
> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>;
> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron
> <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org
> Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3-
> accel
>
> Hi Shameer,
>
>
> On 3/12/25 4:46 PM, Shameerali Kolothum Thodi wrote:
> > Hi Eric,
> >
> >> -----Original Message-----
> >> From: qemu-devel-
> >> bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org <qemu-
> >> devel-bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org>
> On
> >> Behalf Of Eric Auger
> >> Sent: Wednesday, March 12, 2025 3:36 PM
> >> To: Shameerali Kolothum Thodi
> >> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> >> qemu-devel@nongnu.org
> >> Cc: 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; Linuxarm
> >> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>;
> >> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron
> >> <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org
> >> Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for
> >> smmuv3- accel
> >>
> >> Hi Shameer,
> >>
> >>
> >> On 3/11/25 3:10 PM, Shameer Kolothum wrote:
> >>> Allow cold-plug smmuv3-accel to virt If the machine wide smmuv3 is
> >>> not specified.
> >>>
> >>> No FDT support is added for now.
> >>>
> >>> Signed-off-by: Shameer Kolothum
> >> <shameerali.kolothum.thodi@huawei.com>
> >>> ---
> >>> hw/arm/virt.c | 12 ++++++++++++
> >>> hw/core/sysbus-fdt.c | 1 +
> >>> include/hw/arm/virt.h | 1 +
> >>> 3 files changed, 14 insertions(+)
> >>>
> >>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c index
> >>> 4a5a9666e9..84a323da55 100644
> >>> --- a/hw/arm/virt.c
> >>> +++ b/hw/arm/virt.c
> >>> @@ -73,6 +73,7 @@
> >>> #include "qobject/qlist.h"
> >>> #include "standard-headers/linux/input.h"
> >>> #include "hw/arm/smmuv3.h"
> >>> +#include "hw/arm/smmuv3-accel.h"
> >>> #include "hw/acpi/acpi.h"
> >>> #include "target/arm/cpu-qom.h"
> >>> #include "target/arm/internals.h"
> >>> @@ -2911,6 +2912,16 @@ static void
> >> virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
> >>> platform_bus_link_device(PLATFORM_BUS_DEVICE(vms-
> >>> platform_bus_dev),
> >>> SYS_BUS_DEVICE(dev));
> >>> }
> >>> + if (object_dynamic_cast(OBJECT(dev),
> >>> + TYPE_ARM_SMMUV3_ACCEL))
> >> {
> >>> + if (vms->iommu == VIRT_IOMMU_SMMUV3) {
> >> maybe just check whether it is != VIRT_IOMMU_NONE?
> >>> + error_setg(errp,
> >>> + "iommu=smmuv3 is already specified.
> >>> + can't create
> >> smmuv3-accel dev");
> >> I would clearly state "iommu=smmuv3 virt machine option is alreadt set"
> >> and use an error hint to say both are not compatible.
> >>> + return;
> >>> + }
> >>> + if (vms->iommu != VIRT_IOMMU_SMMUV3_ACCEL) {
> >>> + vms->iommu = VIRT_IOMMU_SMMUV3_ACCEL;
> >> I know there were quite a lot of dicussions on the 1st multi
> >> instantiation series related to the way we instanatiate that device
> >> and maybe I missed some blockers but why wouldn't we allow the
> >> instantiation of the legacy smmu device with -device too. I think
> >> this would be simpler for libvirt and we would somehow deprecate the
> >> machine option method? would that make a problem if you were to use
> >> -device smmu,accel or something alike?
> > Thanks for taking a look. I am just jumping on this one for now. Yes,
> > there were discussions around that. But I was not sure we concluded on
> > deprecating the machine option. So if I get you correctly the idea is,
> >
> > if we have,
> > -device smmuv3 it will instantiate the current machine wide smmuv3 and
> > for -device smmuv3,accel this device?
> yes that would be my preference.
Ok. I will look into that in my next respin. A quick question. Does qemu
DEVICE model support the differentiation like above easily? Or we have
to manage it with properties?
Any example device implementation like above already there?
Please let me know.
Thanks,
Shameer
On 3/12/25 5:22 PM, Shameerali Kolothum Thodi wrote:
>
>> -----Original Message-----
>> From: qemu-devel-
>> bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org <qemu-
>> devel-bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org> On
>> Behalf Of Eric Auger
>> Sent: Wednesday, March 12, 2025 4:13 PM
>> To: Shameerali Kolothum Thodi
>> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
>> qemu-devel@nongnu.org
>> Cc: 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; Linuxarm
>> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>;
>> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron
>> <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org
>> Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3-
>> accel
>>
>> Hi Shameer,
>>
>>
>> On 3/12/25 4:46 PM, Shameerali Kolothum Thodi wrote:
>>> Hi Eric,
>>>
>>>> -----Original Message-----
>>>> From: qemu-devel-
>>>> bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org <qemu-
>>>> devel-bounces+shameerali.kolothum.thodi=huawei.com@nongnu.org>
>> On
>>>> Behalf Of Eric Auger
>>>> Sent: Wednesday, March 12, 2025 3:36 PM
>>>> To: Shameerali Kolothum Thodi
>>>> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
>>>> qemu-devel@nongnu.org
>>>> Cc: 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; Linuxarm
>>>> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>;
>>>> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron
>>>> <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org
>>>> Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for
>>>> smmuv3- accel
>>>>
>>>> Hi Shameer,
>>>>
>>>>
>>>> On 3/11/25 3:10 PM, Shameer Kolothum wrote:
>>>>> Allow cold-plug smmuv3-accel to virt If the machine wide smmuv3 is
>>>>> not specified.
>>>>>
>>>>> No FDT support is added for now.
>>>>>
>>>>> Signed-off-by: Shameer Kolothum
>>>> <shameerali.kolothum.thodi@huawei.com>
>>>>> ---
>>>>> hw/arm/virt.c | 12 ++++++++++++
>>>>> hw/core/sysbus-fdt.c | 1 +
>>>>> include/hw/arm/virt.h | 1 +
>>>>> 3 files changed, 14 insertions(+)
>>>>>
>>>>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c index
>>>>> 4a5a9666e9..84a323da55 100644
>>>>> --- a/hw/arm/virt.c
>>>>> +++ b/hw/arm/virt.c
>>>>> @@ -73,6 +73,7 @@
>>>>> #include "qobject/qlist.h"
>>>>> #include "standard-headers/linux/input.h"
>>>>> #include "hw/arm/smmuv3.h"
>>>>> +#include "hw/arm/smmuv3-accel.h"
>>>>> #include "hw/acpi/acpi.h"
>>>>> #include "target/arm/cpu-qom.h"
>>>>> #include "target/arm/internals.h"
>>>>> @@ -2911,6 +2912,16 @@ static void
>>>> virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
>>>>> platform_bus_link_device(PLATFORM_BUS_DEVICE(vms-
>>>>> platform_bus_dev),
>>>>> SYS_BUS_DEVICE(dev));
>>>>> }
>>>>> + if (object_dynamic_cast(OBJECT(dev),
>>>>> + TYPE_ARM_SMMUV3_ACCEL))
>>>> {
>>>>> + if (vms->iommu == VIRT_IOMMU_SMMUV3) {
>>>> maybe just check whether it is != VIRT_IOMMU_NONE?
>>>>> + error_setg(errp,
>>>>> + "iommu=smmuv3 is already specified.
>>>>> + can't create
>>>> smmuv3-accel dev");
>>>> I would clearly state "iommu=smmuv3 virt machine option is alreadt set"
>>>> and use an error hint to say both are not compatible.
>>>>> + return;
>>>>> + }
>>>>> + if (vms->iommu != VIRT_IOMMU_SMMUV3_ACCEL) {
>>>>> + vms->iommu = VIRT_IOMMU_SMMUV3_ACCEL;
>>>> I know there were quite a lot of dicussions on the 1st multi
>>>> instantiation series related to the way we instanatiate that device
>>>> and maybe I missed some blockers but why wouldn't we allow the
>>>> instantiation of the legacy smmu device with -device too. I think
>>>> this would be simpler for libvirt and we would somehow deprecate the
>>>> machine option method? would that make a problem if you were to use
>>>> -device smmu,accel or something alike?
>>> Thanks for taking a look. I am just jumping on this one for now. Yes,
>>> there were discussions around that. But I was not sure we concluded on
>>> deprecating the machine option. So if I get you correctly the idea is,
>>>
>>> if we have,
>>> -device smmuv3 it will instantiate the current machine wide smmuv3 and
>>> for -device smmuv3,accel this device?
>> yes that would be my preference.
> Ok. I will look into that in my next respin. A quick question. Does qemu
> DEVICE model support the differentiation like above easily? Or we have
> to manage it with properties?
Not sure if I understand you question. I meant it can be a boolean
device property (DEFINE_PROP_BOOL) smmuv3,accel=on
No?
Eric
>
> Any example device implementation like above already there?
> Please let me know.
>
> Thanks,
> Shameer
>
>
>
>
> -----Original Message----- > From: Eric Auger <eric.auger@redhat.com> > Sent: Wednesday, March 12, 2025 4:28 PM > To: Shameerali Kolothum Thodi > <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org; > qemu-devel@nongnu.org > Cc: 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; Linuxarm > <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>; > jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron > <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org > Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3- > accel > >> Hi Shameer, > >>>> I know there were quite a lot of dicussions on the 1st multi > >>>> instantiation series related to the way we instanatiate that device > >>>> and maybe I missed some blockers but why wouldn't we allow the > >>>> instantiation of the legacy smmu device with -device too. I think > >>>> this would be simpler for libvirt and we would somehow deprecate > >>>> the machine option method? would that make a problem if you were > to > >>>> use -device smmu,accel or something alike? > >>> Thanks for taking a look. I am just jumping on this one for now. > >>> Yes, there were discussions around that. But I was not sure we > >>> concluded on deprecating the machine option. So if I get you > >>> correctly the idea is, > >>> > >>> if we have, > >>> -device smmuv3 it will instantiate the current machine wide smmuv3 > >>> and for -device smmuv3,accel this device? > >> yes that would be my preference. > > Ok. I will look into that in my next respin. A quick question. Does > > qemu DEVICE model support the differentiation like above easily? Or we > > have to manage it with properties? > Not sure if I understand you question. I meant it can be a boolean device > property (DEFINE_PROP_BOOL) smmuv3,accel=on > > No? Right. My query was more about any hidden Qemu magic to have device instantiation similar to what we have at the moment even though we name both devices "smmuv3". That way I can keep much of the code rather than checking "accel" property in SMMUv3 code and redirecting calls. But looks like not. Thanks, Shameer
Hi Shameer, On 3/12/25 6:34 PM, Shameerali Kolothum Thodi wrote: > >> -----Original Message----- >> From: Eric Auger <eric.auger@redhat.com> >> Sent: Wednesday, March 12, 2025 4:28 PM >> To: Shameerali Kolothum Thodi >> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org; >> qemu-devel@nongnu.org >> Cc: 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; Linuxarm >> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>; >> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron >> <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org >> Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3- >> accel >>>> Hi Shameer, >>>>>> I know there were quite a lot of dicussions on the 1st multi >>>>>> instantiation series related to the way we instanatiate that device >>>>>> and maybe I missed some blockers but why wouldn't we allow the >>>>>> instantiation of the legacy smmu device with -device too. I think >>>>>> this would be simpler for libvirt and we would somehow deprecate >>>>>> the machine option method? would that make a problem if you were >> to >>>>>> use -device smmu,accel or something alike? >>>>> Thanks for taking a look. I am just jumping on this one for now. >>>>> Yes, there were discussions around that. But I was not sure we >>>>> concluded on deprecating the machine option. So if I get you >>>>> correctly the idea is, >>>>> >>>>> if we have, >>>>> -device smmuv3 it will instantiate the current machine wide smmuv3 >>>>> and for -device smmuv3,accel this device? >>>> yes that would be my preference. >>> Ok. I will look into that in my next respin. A quick question. Does >>> qemu DEVICE model support the differentiation like above easily? Or we >>> have to manage it with properties? >> Not sure if I understand you question. I meant it can be a boolean device >> property (DEFINE_PROP_BOOL) smmuv3,accel=on >> >> No? > Right. My query was more about any hidden Qemu magic to have device instantiation > similar to what we have at the moment even though we name both devices "smmuv3". > > That way I can keep much of the code rather than checking "accel" property > in SMMUv3 code and redirecting calls. But looks like not. I don't think there is any such a trick. Having the legacy device (without accel) only instantiable with the virt machine option and the new accelerated one only instantiable with a -device option looks strange to me. By the way they model the same device so I think it makes more sense to use the same device with an option. Also do you see anything that would prevent the acceleration enhanced device from being able to translate emulated devices as well. Ideally the smmu device should react differently depending on the device which is translated. I think it worked with the original implementation as far as I remember. Thanks Eric > > Thanks, > Shameer > > > >
Hi Eric, > -----Original Message----- > From: Eric Auger <eric.auger@redhat.com> > Sent: Wednesday, March 12, 2025 6:31 PM > To: Shameerali Kolothum Thodi > <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org; > qemu-devel@nongnu.org > Cc: 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; Linuxarm > <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>; > jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron > <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org > Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3- > accel > > Hi Shameer, > > > >>>>> Thanks for taking a look. I am just jumping on this one for now. > >>>>> Yes, there were discussions around that. But I was not sure we > >>>>> concluded on deprecating the machine option. So if I get you > >>>>> correctly the idea is, > >>>>> > >>>>> if we have, > >>>>> -device smmuv3 it will instantiate the current machine wide smmuv3 > >>>>> and for -device smmuv3,accel this device? > >>>> yes that would be my preference. > >>> Ok. I will look into that in my next respin. A quick question. Does > >>> qemu DEVICE model support the differentiation like above easily? Or > we > >>> have to manage it with properties? > >> Not sure if I understand you question. I meant it can be a boolean > device > >> property (DEFINE_PROP_BOOL) smmuv3,accel=on > >> > >> No? > > Right. My query was more about any hidden Qemu magic to have device > instantiation > > similar to what we have at the moment even though we name both > devices "smmuv3". > > > > That way I can keep much of the code rather than checking "accel" > property > > in SMMUv3 code and redirecting calls. But looks like not. > I don't think there is any such a trick. > > Having the legacy device (without accel) only instantiable with the virt > machine option and the new accelerated one only instantiable with a > -device option looks strange to me. By the way they model the same > device so I think it makes more sense to use the same device with an > option. Ok. Will address that in the next respin. > Also do you see anything that would prevent the acceleration enhanced > device from being able to translate emulated devices as well. Ideally > the smmu device should react differently depending on the device which > is translated. I think it worked with the original implementation as far > as I remember. Yes, smmuv3-accel works with emulated devices as well. Currently the only limitation is, we should have at least one vfi-pci dev cold plugged as mentioned in the cover letter. Hopefully we will be able to resolve that restriction soon. Thanks, Shameer
On 3/13/25 9:26 AM, Shameerali Kolothum Thodi wrote: > Hi Eric, > >> -----Original Message----- >> From: Eric Auger <eric.auger@redhat.com> >> Sent: Wednesday, March 12, 2025 6:31 PM >> To: Shameerali Kolothum Thodi >> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org; >> qemu-devel@nongnu.org >> Cc: 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; Linuxarm >> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>; >> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron >> <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org >> Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3- >> accel >> >> Hi Shameer, >> >> >>>>>>> Thanks for taking a look. I am just jumping on this one for now. >>>>>>> Yes, there were discussions around that. But I was not sure we >>>>>>> concluded on deprecating the machine option. So if I get you >>>>>>> correctly the idea is, >>>>>>> >>>>>>> if we have, >>>>>>> -device smmuv3 it will instantiate the current machine wide smmuv3 >>>>>>> and for -device smmuv3,accel this device? >>>>>> yes that would be my preference. >>>>> Ok. I will look into that in my next respin. A quick question. Does >>>>> qemu DEVICE model support the differentiation like above easily? Or >> we >>>>> have to manage it with properties? >>>> Not sure if I understand you question. I meant it can be a boolean >> device >>>> property (DEFINE_PROP_BOOL) smmuv3,accel=on >>>> >>>> No? >>> Right. My query was more about any hidden Qemu magic to have device >> instantiation >>> similar to what we have at the moment even though we name both >> devices "smmuv3". >>> That way I can keep much of the code rather than checking "accel" >> property >>> in SMMUv3 code and redirecting calls. But looks like not. >> I don't think there is any such a trick. >> >> Having the legacy device (without accel) only instantiable with the virt >> machine option and the new accelerated one only instantiable with a >> -device option looks strange to me. By the way they model the same >> device so I think it makes more sense to use the same device with an >> option. > Ok. Will address that in the next respin. > >> Also do you see anything that would prevent the acceleration enhanced >> device from being able to translate emulated devices as well. Ideally >> the smmu device should react differently depending on the device which >> is translated. I think it worked with the original implementation as far >> as I remember. > Yes, smmuv3-accel works with emulated devices as well. Currently the only > limitation is, we should have at least one vfi-pci dev cold plugged as mentioned > in the cover letter. Hopefully we will be able to resolve that restriction soon. OK thanks Eric > > Thanks, > Shameer >
On Tue, Mar 11, 2025 at 02:10:29PM +0000, Shameer Kolothum wrote:
> Allow cold-plug smmuv3-accel to virt If the machine wide smmuv3
> is not specified.
>
> No FDT support is added for now.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> hw/arm/virt.c | 12 ++++++++++++
> hw/core/sysbus-fdt.c | 1 +
> include/hw/arm/virt.h | 1 +
> 3 files changed, 14 insertions(+)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 4a5a9666e9..84a323da55 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -73,6 +73,7 @@
> #include "qobject/qlist.h"
> #include "standard-headers/linux/input.h"
> #include "hw/arm/smmuv3.h"
> +#include "hw/arm/smmuv3-accel.h"
smmuv3-accel.h included smmuv3.h in the patch prior.
> @@ -2911,6 +2912,16 @@ static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
> platform_bus_link_device(PLATFORM_BUS_DEVICE(vms->platform_bus_dev),
> SYS_BUS_DEVICE(dev));
> }
> + if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3_ACCEL)) {
> + if (vms->iommu == VIRT_IOMMU_SMMUV3) {
> + error_setg(errp,
> + "iommu=smmuv3 is already specified. can't create smmuv3-accel dev");
> + return;
> + }
> + if (vms->iommu != VIRT_IOMMU_SMMUV3_ACCEL) {
> + vms->iommu = VIRT_IOMMU_SMMUV3_ACCEL;
> + }
Looks like it is to support TYPE_VIRTIO_IOMMU_PCI?
Just asking: should SMMUV3_ACCEL work with that?
Nicolin
> -----Original Message-----
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, March 11, 2025 8:23 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org;
> eric.auger@redhat.com; peter.maydell@linaro.org; jgg@nvidia.com;
> ddutile@redhat.com; berrange@redhat.com; nathanc@nvidia.com;
> mochs@nvidia.com; smostafa@google.com; Linuxarm
> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>;
> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron
> <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org
> Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3-
> accel
>
> On Tue, Mar 11, 2025 at 02:10:29PM +0000, Shameer Kolothum wrote:
> > Allow cold-plug smmuv3-accel to virt If the machine wide smmuv3
> > is not specified.
> >
> > No FDT support is added for now.
> >
> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> > ---
> > hw/arm/virt.c | 12 ++++++++++++
> > hw/core/sysbus-fdt.c | 1 +
> > include/hw/arm/virt.h | 1 +
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index 4a5a9666e9..84a323da55 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -73,6 +73,7 @@
> > #include "qobject/qlist.h"
> > #include "standard-headers/linux/input.h"
> > #include "hw/arm/smmuv3.h"
> > +#include "hw/arm/smmuv3-accel.h"
>
> smmuv3-accel.h included smmuv3.h in the patch prior.
>
> > @@ -2911,6 +2912,16 @@ static void
> virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
> > platform_bus_link_device(PLATFORM_BUS_DEVICE(vms-
> >platform_bus_dev),
> > SYS_BUS_DEVICE(dev));
> > }
> > + if (object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3_ACCEL))
> {
> > + if (vms->iommu == VIRT_IOMMU_SMMUV3) {
> > + error_setg(errp,
> > + "iommu=smmuv3 is already specified. can't create
> smmuv3-accel dev");
> > + return;
> > + }
> > + if (vms->iommu != VIRT_IOMMU_SMMUV3_ACCEL) {
> > + vms->iommu = VIRT_IOMMU_SMMUV3_ACCEL;
> > + }
>
> Looks like it is to support TYPE_VIRTIO_IOMMU_PCI?
>
> Just asking: should SMMUV3_ACCEL work with that?
Hmm..That's true. It will conflict with virtio-iommu. I will add
a blocker if both are specified.
Thanks,
Shameer
© 2016 - 2025 Red Hat, Inc.