> -----Original Message----- > From: Donald Dutile <ddut...@redhat.com> > Sent: Friday, April 18, 2025 9:34 PM > To: Shameerali Kolothum Thodi > <shameerali.kolothum.th...@huawei.com>; qemu-...@nongnu.org; > qemu-devel@nongnu.org > Cc: eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvidia.com; > nicol...@nvidia.com; berra...@redhat.com; nath...@nvidia.com; > mo...@nvidia.com; smost...@google.com; Linuxarm > <linux...@huawei.com>; Wangzhou (B) <wangzh...@hisilicon.com>; > jiangkunkun <jiangkun...@huawei.com>; Jonathan Cameron > <jonathan.came...@huawei.com>; zhangfei....@linaro.org > Subject: Re: [PATCH 0/5] Add support for user creatable SMMUv3 device > > Shameer, > Hi! > > First off, like the partitioning of these pieces. > > On 4/15/25 4:10 AM, Shameer Kolothum wrote: > > Hi All, > > > > This patch series introduces support for a user-creatable SMMUv3 device > > (-device arm-smmuv3-dev) in QEMU. > > > Can we drop the '-dev', as 'arm-smmu' is sufficient, as is '-device'? > > I know, internal to QEMU, there's already an ARM_SMMU, but as suggested > later, > if it uses the same struct, the qemu cmdline syntax is a bit less redundant.
Trust me I tried that😊. The problem is that, the legacy one doesn't have a bus associated with it and the moment we change that and have bus specified for the "-device arm-smmuv3, bus=pcie.0" the legacy smmuv3 creation in virt, create_smmu() --> qdev_new(TYPE_ARM_SMMUV3) will fails as it expects the bus type to be specified for it. I couldn't find a way to solve that. > > > The implementation is based on feedback received from the RFCv2[0]: > > "hw/arm/virt: Add support for user-creatable accelerated SMMUv3" > > > > Currently, QEMU's SMMUv3 emulation (iommu=smmuv3) is tied to the > machine > > and does not support instantiating multiple SMMUv3 devices—each > associated > > with a separate PCIe root complex. In contrast, real-world ARM systems > > often include multiple SMMUv3 instances, each bound to a different PCIe > > root complex. > > > > This also lays the groundwork for supporting accelerated SMMUv3, as > > proposed in the aforementioned RFC. Please note, the > accelerated SMMUv3 > > support is not part of this series and will be sent out as a separate > > series later on top of this one. > > > > Summary of changes: > > > > -Introduces support for multiple -device arm-smmuv3-dev,bus=pcie.x > > instances. > > > > Example usage: > > > > -device arm-smmuv3-dev,bus=pcie.0 > > -device virtio-net-pci,bus=pcie.0 > > -device pxb-pcie,id=pcie.1,bus_nr=2 > > -device arm-smmuv3-dev,bus=pcie.1 > > -device pcie-root-port,id=pcie.port1,bus=pcie.1 > > -device virtio-net-pci,bus=pcie.port1 > > > > -Supports either the legacy iommu=smmuv3 option or the new > > "-device arm-smmuv3-dev" model. > > > nice! :) > Can it support both? i.e., some devices using a system-wide, legacy > smmuv3, > and some pcie devices using the -device arm-smmuv3 ? Please see my reply to patch #2. In short No, it doesn't support both. Also I think we should slowly deprecate the use of legacy SMMUv3 going forward unless there is a strong use case/reason to support it. > If not, then add a check to min-warn or max-fail, that config. > I can see old machines being converted/upgraded to new machines, > and they will want to switch from legacy->device smmuv3, and catching > an edit/update to a machine change (or enabling automated conversion) > would be helpful. Please see Patch #4. It already checks and prevents if incompatible SMMUv3 types are specified. Or is the suggestion here is to add something extra? Please let me know. Thanks, Shameer
