qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@redhat.com>
To: "Donald Dutile" <ddutile@redhat.com>,
	"Shameer Kolothum" <shameerali.kolothum.thodi@huawei.com>,
	qemu-arm@nongnu.org, qemu-devel@nongnu.org,
	"Markus Armbruster" <armbru@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Cc: jgg@nvidia.com, nicolinc@nvidia.com, berrange@redhat.com,
	nathanc@nvidia.com, mochs@nvidia.com, smostafa@google.com,
	linuxarm@huawei.com, wangzhou1@hisilicon.com,
	jiangkunkun@huawei.com, jonathan.cameron@huawei.com,
	zhangfei.gao@linaro.org
Subject: Re: [PATCH v2 1/6] hw/arm/smmuv3: Add support to associate a PCIe RC
Date: Mon, 5 May 2025 10:19:08 +0200	[thread overview]
Message-ID: <fd3219d3-bab3-4991-afbe-fd80549bbca4@redhat.com> (raw)
In-Reply-To: <03c31d89-ad24-4470-99d0-a77e693e3ba2@redhat.com>

Hi,
On 5/2/25 8:16 PM, Donald Dutile wrote:
>
>
> On 5/2/25 6:27 AM, Shameer Kolothum wrote:
>> Although this change does not affect functionality at present, it lays
>> the groundwork for enabling user-created SMMUv3 devices in
>> future patches
>>
>> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
>> ---
>>   hw/arm/smmuv3.c | 26 ++++++++++++++++++++++++++
>>   hw/arm/virt.c   |  3 ++-
>>   2 files changed, 28 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
>> index ab67972353..605de9b721 100644
>> --- a/hw/arm/smmuv3.c
>> +++ b/hw/arm/smmuv3.c
>> @@ -24,6 +24,7 @@
>>   #include "hw/qdev-properties.h"
>>   #include "hw/qdev-core.h"
>>   #include "hw/pci/pci.h"
>> +#include "hw/pci/pci_bridge.h"
>>   #include "cpu.h"
>>   #include "exec/target_page.h"
>>   #include "trace.h"
>> @@ -1874,6 +1875,25 @@ static void smmu_reset_exit(Object *obj,
>> ResetType type)
>>       smmuv3_init_regs(s);
>>   }
>>   +static int smmuv3_pcie_bus(Object *obj, void *opaque)
>> +{
>> +    DeviceState *d = opaque;
>> +    PCIBus *bus;
>> +
>> +    if (!object_dynamic_cast(obj, TYPE_PCI_HOST_BRIDGE)) {
>> +        return 0;
>> +    }
>> +
>> +    bus = PCI_HOST_BRIDGE(obj)->bus;
>> +    if (d->parent_bus && !strcmp(bus->qbus.name,
>> d->parent_bus->name)) {
>> +        object_property_set_link(OBJECT(d), "primary-bus", OBJECT(bus),
>> +                                 &error_abort);
>> +        /* Return non-zero as we got the bus and don't need further
>> iteration.*/
>> +        return 1;
>> +    }
>> +    return 0;
>> +}
>> +
>>   static void smmu_realize(DeviceState *d, Error **errp)
>>   {
>>       SMMUState *sys = ARM_SMMU(d);
>> @@ -1882,6 +1902,10 @@ static void smmu_realize(DeviceState *d, Error
>> **errp)
>>       SysBusDevice *dev = SYS_BUS_DEVICE(d);
>>       Error *local_err = NULL;
>>   +    if (!object_property_get_link(OBJECT(d), "primary-bus",
>> &error_abort)) {
>> +        object_child_foreach_recursive(object_get_root(),
>> smmuv3_pcie_bus, d);
>> +    }
>> +
>>       c->parent_realize(d, &local_err);
>>       if (local_err) {
>>           error_propagate(errp, local_err);
>> @@ -1996,6 +2020,8 @@ static void smmuv3_class_init(ObjectClass
>> *klass, const void *data)
>>       device_class_set_parent_realize(dc, smmu_realize,
>>                                       &c->parent_realize);
>>       device_class_set_props(dc, smmuv3_properties);
>> +    dc->hotpluggable = false;
>> +    dc->bus_type = TYPE_PCIE_BUS;
> Does this force legacy SMMUv3 to be tied to a PCIe bus now?
> if so, will that break some existing legacy smmuv3 configs?, i.e.,
> virtio-scsi attached to a legacy smmuv3.

Previously the SMMU was already always attached to a PCI primary-bus
(vms->bus ie. pci0). virtio-scsi-pci is the device being protected. The
SMMU is not able to protect platforms devices atm.

My only concern is we are highjacking the "bus" prop to record the bus
hierarchy the SMMU is protecting. While the SMMU is a platform device
and does not inherit the PCI device base class its bus type becomes
"TYPE_PCIE_BUS". So in terms of qom hierachy is is seen as a PCI device
now? I don't know if it is a problem. An alternative could be to keep
the bus pointer and type as it was before and introduce a primary-bus
property. Adding Markus, Peter, Daniel and Alex in to.

At some point it was envisionned to support protected platform devices
(I think this was need for CCA). My fear is that if we turn the bus type
to PCIE it may be difficult to extend the support to non PCIe protected
devices. The SMMU shall remain a platform device being able to protect
either PCI devices and, in the future, platform devices.

Thanks

Eric
>
>>   }
>>     static int smmuv3_notify_flag_changed(IOMMUMemoryRegion *iommu,
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 177f3dd22c..3bae4e374f 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -56,6 +56,7 @@
>>   #include "qemu/cutils.h"
>>   #include "qemu/error-report.h"
>>   #include "qemu/module.h"
>> +#include "hw/pci/pci_bus.h"
>>   #include "hw/pci-host/gpex.h"
>>   #include "hw/virtio/virtio-pci.h"
>>   #include "hw/core/sysbus-fdt.h"
>> @@ -1442,7 +1443,7 @@ static void create_smmu(const VirtMachineState
>> *vms,
>>       }
>>       object_property_set_link(OBJECT(dev), "primary-bus", OBJECT(bus),
>>                                &error_abort);
>> -    sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
>> +    qdev_realize_and_unref(dev, &bus->qbus, &error_fatal);
>>       sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
>>       for (i = 0; i < NUM_SMMU_IRQS; i++) {
>>           sysbus_connect_irq(SYS_BUS_DEVICE(dev), i,
>



  reply	other threads:[~2025-05-05  8:20 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-02 10:27 [PATCH v2 0/6] Add support for user creatable SMMUv3 device Shameer Kolothum via
2025-05-02 10:27 ` [PATCH v2 1/6] hw/arm/smmuv3: Add support to associate a PCIe RC Shameer Kolothum via
2025-05-02 17:22   ` Nicolin Chen
2025-05-06  8:14     ` Shameerali Kolothum Thodi via
2025-05-02 18:16   ` Donald Dutile
2025-05-05  8:19     ` Eric Auger [this message]
2025-05-06  9:07       ` Shameerali Kolothum Thodi via
2025-05-06  9:35         ` Eric Auger
2025-05-06  8:42     ` Shameerali Kolothum Thodi via
2025-05-06 11:47   ` Markus Armbruster
2025-05-06 12:20     ` Shameerali Kolothum Thodi via
2025-05-06 20:48     ` Donald Dutile
2025-05-07  7:17       ` Markus Armbruster
2025-05-07  8:50         ` Shameerali Kolothum Thodi via
2025-05-08 13:45           ` Donald Dutile
2025-05-08 13:57             ` Peter Maydell
2025-05-09  7:57               ` Markus Armbruster
2025-05-09  8:00               ` Shameerali Kolothum Thodi via
2025-05-09 10:37                 ` Peter Maydell
2025-05-09 10:46                   ` Daniel P. Berrangé
2025-05-09 11:43                     ` Peter Maydell
2025-05-22  7:39                       ` Shameerali Kolothum Thodi via
2025-05-16 20:53               ` Donald Dutile
2025-05-09  7:29             ` Shameerali Kolothum Thodi via
2025-05-09  8:14               ` Daniel P. Berrangé
2025-05-09  8:18                 ` Shameerali Kolothum Thodi via
2025-05-09  8:44                   ` Eric Auger
2025-05-02 10:27 ` [PATCH v2 2/6] hw/arm/virt-acpi-build: Update IORT for multiple smmuv3 devices Shameer Kolothum via
2025-05-02 17:13   ` Nicolin Chen
2025-05-02 18:18     ` Donald Dutile
2025-05-06  8:43       ` Shameerali Kolothum Thodi via
2025-05-06  8:00     ` Shameerali Kolothum Thodi via
2025-05-05  8:39   ` Eric Auger
2025-05-06  9:12     ` Shameerali Kolothum Thodi via
2025-05-02 10:27 ` [PATCH v2 3/6] hw/arm/virt: Factor out common SMMUV3 dt bindings code Shameer Kolothum via
2025-05-02 17:15   ` Nicolin Chen
2025-05-05  9:01   ` Eric Auger
2025-05-06  9:19     ` Shameerali Kolothum Thodi via
2025-05-02 10:27 ` [PATCH v2 4/6] hw/arm/virt: Add an SMMU_IO_LEN macro Shameer Kolothum via
2025-05-02 18:20   ` Donald Dutile
2025-05-05  9:03   ` Eric Auger
2025-05-02 10:27 ` [PATCH v2 5/6] hw/arm/virt: Add support for smmuv3 device Shameer Kolothum via
2025-05-02 17:54   ` Nicolin Chen
2025-05-06  8:36     ` Shameerali Kolothum Thodi via
2025-05-05 10:12   ` Eric Auger
2025-05-06  9:29     ` Shameerali Kolothum Thodi via
2025-05-02 10:27 ` [PATCH v2 6/6] hw/arm/smmuv3: Enable smmuv3 device creation Shameer Kolothum via
2025-05-02 18:00   ` Nicolin Chen
2025-05-05 10:13   ` Eric Auger
2025-05-02 18:11 ` [PATCH v2 0/6] Add support for user creatable SMMUv3 device Donald Dutile

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=fd3219d3-bab3-4991-afbe-fd80549bbca4@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=jiangkunkun@huawei.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linuxarm@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=shameerali.kolothum.thodi@huawei.com \
    --cc=smostafa@google.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).