From: Eric Auger <eric.auger@redhat.com>
To: Shameer Kolothum <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, linuxarm@huawei.com, wangzhou1@hisilicon.com,
jiangkunkun@huawei.com, jonathan.cameron@huawei.com,
zhangfei.gao@linaro.org
Subject: Re: [RFC PATCH 2/5] hw/arm/smmuv3: Add initial support for SMMUv3 Nested device
Date: Wed, 13 Nov 2024 18:12:15 +0100 [thread overview]
Message-ID: <00e8a5d6-c926-44bb-8d11-dab4ddc4820d@redhat.com> (raw)
In-Reply-To: <20241108125242.60136-3-shameerali.kolothum.thodi@huawei.com>
Hi Shameer,
On 11/8/24 13:52, Shameer Kolothum wrote:
> Based on SMMUv3 as a parent device, add a user-creatable
> smmuv3-nested device. Subsequent patches will add support to
> specify a PCI bus for this device.
>
> Currently only supported for "virt", so hook up the sybus mem & irq
> for that as well.
>
> No FDT support is added for now.
>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
> hw/arm/smmuv3.c | 34 ++++++++++++++++++++++++++++++++++
> hw/arm/virt.c | 31 +++++++++++++++++++++++++++++--
> hw/core/sysbus-fdt.c | 1 +
> include/hw/arm/smmuv3.h | 15 +++++++++++++++
> include/hw/arm/virt.h | 6 ++++++
> 5 files changed, 85 insertions(+), 2 deletions(-)
>
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index 2101031a8f..0033eb8125 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -2201,6 +2201,19 @@ static void smmu_realize(DeviceState *d, Error **errp)
> smmu_init_irq(s, dev);
> }
>
> +static void smmu_nested_realize(DeviceState *d, Error **errp)
> +{
> + SMMUv3NestedState *s_nested = ARM_SMMUV3_NESTED(d);
nit: s/s_nested/ns or just s?
> + SMMUv3NestedClass *c = ARM_SMMUV3_NESTED_GET_CLASS(s_nested);
> + Error *local_err = NULL;
> +
> + c->parent_realize(d, &local_err);
I think it is safe to use errp directly here.
> + if (local_err) {
> + error_propagate(errp, local_err);
> + return;
> + }
> +}
> +
> static const VMStateDescription vmstate_smmuv3_queue = {
> .name = "smmuv3_queue",
> .version_id = 1,
> @@ -2299,6 +2312,18 @@ static void smmuv3_class_init(ObjectClass *klass, void *data)
> device_class_set_props(dc, smmuv3_properties);
> }
>
> +static void smmuv3_nested_class_init(ObjectClass *klass, void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + SMMUv3NestedClass *c = ARM_SMMUV3_NESTED_CLASS(klass);
> +
> + dc->vmsd = &vmstate_smmuv3;
> + device_class_set_parent_realize(dc, smmu_nested_realize,
> + &c->parent_realize);
> + dc->user_creatable = true;
> + dc->hotpluggable = false;
> +}
> +
> static int smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu,
> IOMMUNotifierFlag old,
> IOMMUNotifierFlag new,
> @@ -2337,6 +2362,14 @@ static void smmuv3_iommu_memory_region_class_init(ObjectClass *klass,
> imrc->notify_flag_changed = smmuv3_notify_flag_changed;
> }
>
> +static const TypeInfo smmuv3_nested_type_info = {
> + .name = TYPE_ARM_SMMUV3_NESTED,
> + .parent = TYPE_ARM_SMMUV3,
> + .instance_size = sizeof(SMMUv3NestedState),
> + .class_size = sizeof(SMMUv3NestedClass),
> + .class_init = smmuv3_nested_class_init,
> +};
> +
> static const TypeInfo smmuv3_type_info = {
> .name = TYPE_ARM_SMMUV3,
> .parent = TYPE_ARM_SMMU,
> @@ -2355,6 +2388,7 @@ static const TypeInfo smmuv3_iommu_memory_region_info = {
> static void smmuv3_register_types(void)
> {
> type_register(&smmuv3_type_info);
> + type_register(&smmuv3_nested_type_info);
> type_register(&smmuv3_iommu_memory_region_info);
> }
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 780bcff77c..38075f9ab2 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -181,6 +181,7 @@ static const MemMapEntry base_memmap[] = {
> [VIRT_PVTIME] = { 0x090a0000, 0x00010000 },
> [VIRT_SECURE_GPIO] = { 0x090b0000, 0x00001000 },
> [VIRT_MMIO] = { 0x0a000000, 0x00000200 },
> + [VIRT_SMMU_NESTED] = { 0x0b000000, 0x01000000 },
I agree with Mostafa that the _NESTED terminology may not be the best
choice.
The motivation behind that multi-instance attempt, as introduced in
https://lore.kernel.org/all/ZEcT%2F7erkhHDaNvD@Asurada-Nvidia/
was:
- SMMUs with different feature bits
- support of VCMDQ HW extension for SMMU CMDQ
- need for separate S1 invalidation paths
If I understand correctly this is mostly wanted for VCMDQ handling? if
this is correct we may indicate that somehow in the terminology.
If I understand correctly VCMDQ terminology is NVidia specific while
ECMDQ is the baseline (?).
> /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */
> [VIRT_PLATFORM_BUS] = { 0x0c000000, 0x02000000 },
> [VIRT_SECURE_MEM] = { 0x0e000000, 0x01000000 },
> @@ -226,6 +227,7 @@ static const int a15irqmap[] = {
> [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */
> [VIRT_SMMU] = 74, /* ...to 74 + NUM_SMMU_IRQS - 1 */
> [VIRT_PLATFORM_BUS] = 112, /* ...to 112 + PLATFORM_BUS_NUM_IRQS -1 */
> + [VIRT_SMMU_NESTED] = 200,
What is the max IRQs expected to be consumed. Wother to comment for next
interrupt user.
> };
>
> static void create_randomness(MachineState *ms, const char *node)
> @@ -2883,10 +2885,34 @@ static void virt_machine_device_plug_cb(HotplugHandler *hotplug_dev,
> DeviceState *dev, Error **errp)
> {
> VirtMachineState *vms = VIRT_MACHINE(hotplug_dev);
> + MachineClass *mc = MACHINE_GET_CLASS(vms);
>
> - if (vms->platform_bus_dev) {
> - MachineClass *mc = MACHINE_GET_CLASS(vms);
> + /* For smmuv3-nested devices we need to set the mem & irq */
> + if (device_is_dynamic_sysbus(mc, dev) &&
> + object_dynamic_cast(OBJECT(dev), TYPE_ARM_SMMUV3_NESTED)) {
why did you choose not using the PLATFORM BUS infra which does that kind
of binding automatically (also it provisions for dedicated MMIOs and
IRQs). At least you would need to justify in the commit msg I think
> + hwaddr base = vms->memmap[VIRT_SMMU_NESTED].base;
> + int irq = vms->irqmap[VIRT_SMMU_NESTED];
> +
> + if (vms->smmu_nested_count >= MAX_SMMU_NESTED) {
> + error_setg(errp, "smmuv3-nested max count reached!");
> + return;
> + }
> +
> + base += (vms->smmu_nested_count * SMMU_IO_LEN);
> + irq += (vms->smmu_nested_count * NUM_SMMU_IRQS);
>
> + sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
> + for (int i = 0; i < 4; i++) {
> + sysbus_connect_irq(SYS_BUS_DEVICE(dev), i,
> + qdev_get_gpio_in(vms->gic, irq + i));
> + }
> + if (vms->iommu != VIRT_IOMMU_SMMUV3_NESTED) {
> + vms->iommu = VIRT_IOMMU_SMMUV3_NESTED;
> + }
> + vms->smmu_nested_count++;
this kind of check would definitively not integrated in the platform bus
but this could be introduced generically in the framework though or
special cased after the platform_bus_link_device
> + }
> +
> + if (vms->platform_bus_dev) {
> if (device_is_dynamic_sysbus(mc, dev)) {
> platform_bus_link_device(PLATFORM_BUS_DEVICE(vms->platform_bus_dev),
> SYS_BUS_DEVICE(dev));
> @@ -3067,6 +3093,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_NESTED);
> #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 eebcd28f9a..0f0d0b3e58 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-nested", 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/smmuv3.h b/include/hw/arm/smmuv3.h
> index d183a62766..87e628be7a 100644
> --- a/include/hw/arm/smmuv3.h
> +++ b/include/hw/arm/smmuv3.h
> @@ -84,6 +84,21 @@ struct SMMUv3Class {
> #define TYPE_ARM_SMMUV3 "arm-smmuv3"
> OBJECT_DECLARE_TYPE(SMMUv3State, SMMUv3Class, ARM_SMMUV3)
>
> +#define TYPE_ARM_SMMUV3_NESTED "arm-smmuv3-nested"
> +OBJECT_DECLARE_TYPE(SMMUv3NestedState, SMMUv3NestedClass, ARM_SMMUV3_NESTED)
> +
> +struct SMMUv3NestedState {
> + SMMUv3State smmuv3_state;
> +};
> +
> +struct SMMUv3NestedClass {
> + /*< private >*/
> + SMMUv3Class smmuv3_class;
> + /*< public >*/
> +
> + DeviceRealize parent_realize;
> +};
> +
> #define STAGE1_SUPPORTED(s) FIELD_EX32(s->idr[0], IDR0, S1P)
> #define STAGE2_SUPPORTED(s) FIELD_EX32(s->idr[0], IDR0, S2P)
>
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index 46f48fe561..50e47a4ef3 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -50,6 +50,9 @@
> /* MMIO region size for SMMUv3 */
> #define SMMU_IO_LEN 0x20000
>
> +/* Max supported nested SMMUv3 */
> +#define MAX_SMMU_NESTED 128
Ouch, that many?!
> +
> enum {
> VIRT_FLASH,
> VIRT_MEM,
> @@ -62,6 +65,7 @@ enum {
> VIRT_GIC_ITS,
> VIRT_GIC_REDIST,
> VIRT_SMMU,
> + VIRT_SMMU_NESTED,
> VIRT_UART0,
> VIRT_MMIO,
> VIRT_RTC,
> @@ -92,6 +96,7 @@ enum {
> typedef enum VirtIOMMUType {
> VIRT_IOMMU_NONE,
> VIRT_IOMMU_SMMUV3,
> + VIRT_IOMMU_SMMUV3_NESTED,
> VIRT_IOMMU_VIRTIO,
> } VirtIOMMUType;
>
> @@ -155,6 +160,7 @@ struct VirtMachineState {
> bool mte;
> bool dtb_randomness;
> bool second_ns_uart_present;
> + int smmu_nested_count;
> OnOffAuto acpi;
> VirtGICType gic_version;
> VirtIOMMUType iommu;
Thanks
Eric
next prev parent reply other threads:[~2024-11-13 17:13 UTC|newest]
Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 12:52 [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested SMMUv3 Shameer Kolothum via
2024-11-08 12:52 ` [RFC PATCH 1/5] hw/arm/virt: Add an SMMU_IO_LEN macro Shameer Kolothum via
2024-11-13 16:48 ` Eric Auger
2024-11-08 12:52 ` [RFC PATCH 2/5] hw/arm/smmuv3: Add initial support for SMMUv3 Nested device Shameer Kolothum via
2024-11-13 17:12 ` Eric Auger [this message]
2024-11-13 18:05 ` Nicolin Chen
2024-11-26 18:28 ` Donald Dutile
2024-11-27 10:21 ` Shameerali Kolothum Thodi via
2024-11-27 16:00 ` Jason Gunthorpe
2024-11-27 16:05 ` Eric Auger
2024-11-28 3:25 ` Zhangfei Gao
2024-11-28 8:06 ` Eric Auger
2024-11-28 8:28 ` Shameerali Kolothum Thodi via
2024-11-28 8:41 ` Eric Auger
2024-11-28 12:52 ` Jason Gunthorpe
2024-11-27 23:03 ` Donald Dutile
2024-11-28 12:51 ` Jason Gunthorpe
2024-11-28 4:29 ` Donald Dutile
2024-11-28 4:44 ` Nicolin Chen
2024-11-28 12:54 ` Jason Gunthorpe
2024-11-28 18:22 ` Nicolin Chen
2024-12-02 18:53 ` Donald Dutile
2024-11-28 8:17 ` Shameerali Kolothum Thodi via
2024-11-14 8:20 ` Shameerali Kolothum Thodi via
2024-11-14 8:41 ` Eric Auger
2024-11-14 13:27 ` Shameerali Kolothum Thodi via
2024-11-15 22:32 ` Nicolin Chen
2024-11-13 18:00 ` Eric Auger
2024-11-08 12:52 ` [RFC PATCH 3/5] hw/arm/smmuv3: Associate a pci bus with a " Shameer Kolothum via
2024-11-13 17:58 ` Eric Auger
2024-11-14 8:30 ` Shameerali Kolothum Thodi via
2025-01-30 16:29 ` Daniel P. Berrangé
2025-01-30 18:19 ` Shameerali Kolothum Thodi via
2024-11-08 12:52 ` [RFC PATCH 4/5] hw/arm/virt-acpi-build: Build IORT with multiple SMMU nodes Shameer Kolothum via
2024-11-18 10:01 ` Eric Auger
2024-11-18 11:44 ` Shameerali Kolothum Thodi via
2024-11-18 13:45 ` Eric Auger
2024-11-18 15:00 ` Shameerali Kolothum Thodi via
2024-11-18 18:09 ` Eric Auger
2024-11-20 14:16 ` Shameerali Kolothum Thodi via
2024-11-20 16:10 ` Eric Auger
2024-11-20 16:26 ` Shameerali Kolothum Thodi via
2024-11-21 9:46 ` Shameerali Kolothum Thodi via
2024-12-10 20:48 ` Nicolin Chen
2024-12-11 15:21 ` Shameerali Kolothum Thodi via
2024-12-13 0:28 ` Nicolin Chen
2024-11-08 12:52 ` [RFC PATCH 5/5] hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested binding Shameer Kolothum via
2024-11-13 18:31 ` Nicolin Chen
2024-11-14 8:48 ` Shameerali Kolothum Thodi via
2024-11-14 10:41 ` Eric Auger
2024-11-15 22:12 ` Nicolin Chen
2024-12-10 23:01 ` Nicolin Chen
2024-12-11 0:48 ` Jason Gunthorpe
2024-12-11 1:28 ` Nicolin Chen
2024-12-11 13:11 ` Jason Gunthorpe
2024-12-11 17:20 ` Nicolin Chen
2024-12-11 18:01 ` Jason Gunthorpe
2024-11-12 22:59 ` [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested SMMUv3 Nicolin Chen
2024-11-14 7:56 ` Shameerali Kolothum Thodi via
2024-11-20 23:59 ` Nathan Chen
2024-11-21 10:12 ` Shameerali Kolothum Thodi via
2024-11-22 1:41 ` Nathan Chen
2024-11-22 17:38 ` Shameerali Kolothum Thodi via
2024-11-22 18:53 ` Nathan Chen
2025-02-04 14:00 ` Eric Auger
2024-12-13 11:58 ` Daniel P. Berrangé
2024-12-13 12:43 ` Jason Gunthorpe
2024-12-12 23:54 ` Nathan Chen
2024-12-13 1:01 ` Nathan Chen
2024-12-16 9:31 ` Shameerali Kolothum Thodi via
2025-01-25 2:43 ` Nathan Chen
2025-01-27 15:26 ` Shameerali Kolothum Thodi via
2025-01-27 23:35 ` Nathan Chen
2024-11-13 16:16 ` Mostafa Saleh
2024-11-14 8:01 ` Shameerali Kolothum Thodi via
2024-11-14 11:49 ` Mostafa Saleh
2024-11-13 21:42 ` Nicolin Chen
2024-11-14 9:11 ` Shameerali Kolothum Thodi via
2024-11-18 10:50 ` Eric Auger
2025-01-30 16:41 ` Daniel P. Berrangé
2024-12-13 12:00 ` Daniel P. Berrangé
2024-12-13 12:46 ` Jason Gunthorpe
2024-12-13 13:19 ` Daniel P. Berrangé
2024-12-16 9:38 ` Shameerali Kolothum Thodi via
2024-12-17 18:36 ` Donald Dutile
2024-12-13 13:33 ` Peter Maydell
2024-12-16 10:01 ` Shameerali Kolothum Thodi via
2025-01-09 4:45 ` Nicolin Chen
2025-01-11 4:05 ` Donald Dutile
2025-01-23 4:10 ` Nicolin Chen
2025-01-23 8:28 ` Shameerali Kolothum Thodi via
2025-01-23 8:40 ` Nicolin Chen
2025-01-23 11:07 ` Duan, Zhenzhong
2025-02-17 9:17 ` Duan, Zhenzhong
2025-02-18 6:52 ` Shameerali Kolothum Thodi via
2025-03-06 17:59 ` Eric Auger
2025-03-06 18:27 ` Shameerali Kolothum Thodi via
2025-03-06 18:40 ` Eric Auger
2025-01-31 16:54 ` Eric Auger
2025-02-03 18:50 ` Nicolin Chen
2025-02-04 17:49 ` Eric Auger
2025-02-05 0:08 ` Nicolin Chen
2025-02-05 10:43 ` Shameerali Kolothum Thodi via
2025-02-05 12:35 ` Eric Auger
2025-02-06 10:34 ` Shameerali Kolothum Thodi via
2025-02-06 18:58 ` Nicolin Chen
2025-03-03 15:21 ` Shameerali Kolothum Thodi via
2025-03-03 17:04 ` Nicolin Chen
2025-03-04 9:30 ` Shameerali Kolothum Thodi via
2025-01-30 16:00 ` Daniel P. Berrangé
2025-01-30 18:09 ` Shameerali Kolothum Thodi via
2025-01-31 9:33 ` Shameerali Kolothum Thodi via
2025-01-31 10:07 ` Eric Auger
2025-01-31 14:24 ` Jason Gunthorpe
2025-01-31 14:39 ` Shameerali Kolothum Thodi via
2025-01-31 14:54 ` Jason Gunthorpe
2025-01-31 15:23 ` Shameerali Kolothum Thodi via
2025-01-31 16:08 ` Eric Auger
2025-02-05 20:53 ` Nathan Chen
2025-02-06 8:54 ` Daniel P. Berrangé
2025-02-06 8:53 ` Daniel P. Berrangé
2025-02-06 16:44 ` Eric Auger
2025-01-31 21:41 ` Daniel P. Berrangé
2025-02-06 10:02 ` Shameerali Kolothum Thodi via
2025-02-06 10:37 ` Daniel P. Berrangé
2025-02-06 13:51 ` Shameerali Kolothum Thodi via
2025-02-06 14:46 ` Daniel P. Berrangé
2025-02-06 15:07 ` Shameerali Kolothum Thodi via
2025-02-06 17:02 ` Jason Gunthorpe
2025-02-06 17:10 ` Daniel P. Berrangé
2025-02-06 17:46 ` Jason Gunthorpe
2025-02-06 17:54 ` Daniel P. Berrangé
2025-02-06 17:58 ` Jason Gunthorpe
2025-02-06 18:04 ` Shameerali Kolothum Thodi via
2025-02-06 18:13 ` Jason Gunthorpe
2025-02-06 18:18 ` Shameerali Kolothum Thodi via
2025-02-06 18:22 ` Jason Gunthorpe
2025-02-06 20:33 ` Nicolin Chen
2025-02-06 20:38 ` Jason Gunthorpe
2025-02-06 20:48 ` Nicolin Chen
2025-02-06 21:11 ` Jason Gunthorpe
2025-02-06 22:46 ` Nicolin Chen
2025-02-07 0:08 ` Jason Gunthorpe
2025-02-07 10:21 ` Shameerali Kolothum Thodi via
2025-02-07 10:31 ` Daniel P. Berrangé
2025-02-07 12:21 ` Shameerali Kolothum Thodi via
2025-02-07 12:53 ` Jason Gunthorpe
2025-02-06 18:18 ` Daniel P. Berrangé
2025-02-06 17:57 ` Shameerali Kolothum Thodi via
2025-02-06 17:59 ` Jason Gunthorpe
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=00e8a5d6-c926-44bb-8d11-dab4ddc4820d@redhat.com \
--to=eric.auger@redhat.com \
--cc=ddutile@redhat.com \
--cc=jgg@nvidia.com \
--cc=jiangkunkun@huawei.com \
--cc=jonathan.cameron@huawei.com \
--cc=linuxarm@huawei.com \
--cc=nicolinc@nvidia.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=wangzhou1@hisilicon.com \
--cc=zhangfei.gao@linaro.org \
/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).