On 4/22/25 4:57 AM, Shameerali Kolothum Thodi wrote:
-----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.
I guessed that's why there was new syntax for what is basically an extension of
previous syntax.
I'll dig more into it and see if there's a way to handle it.
qemu does handle varying added params (id=blah, no id=blah),
so I'm researching how that's done, to figure out how the legacy, smmu-for-all,
and the smmu-for-specific pcie<RC> can both be supported.
Given your stated trials and tribulations, this should be fun. ;-)
- Don
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
