On Wed, Nov 27, 2024 at 11:29:06PM -0500, Donald Dutile wrote: > On 11/27/24 5:21 AM, Shameerali Kolothum Thodi wrote: > > > > W.r.t naming, maybe something related to "hardware-accelerated"? > > > > > > > Given that 'accel' has been used for hw-acceleration elsewhere, that seems > > > like a reasonable 'mode'. > > > But, it needs a paramater to state was is being accelerated. > > > i.e., the more global 'accel=kvm' has 'kvm'. > > > > I was thinking more like calling this hw accelerated nested SMMUv3 emulation > > as 'smmuv3-accel'. This avoids confusion with the already existing > > 'iommu=smmuv3' that also has a nested emulation support. > > > > ie, > > -device arm-smmuv3-accel,id=smmuv1,bus=pcie.1 \ > > .. > I -think- you are saying below, that we have to think a bit more about this > device tagging. I'm thinking more like > - device arm-smmuv3,accel=<vcmdq>,id=smmu1,bus=pcie.1 \
I wonder if we really need a "vcmdq" enabling/disabling option? Jason's suggested approach for a vIOMMU allocation is to retry- on-failure, so my draft patches allocate a TEGRA241_CMDQV type of vIOMMU first, and then fall back to a regular SMMUV3 type if it fails. So, a host that doesn't have a VCMDQ capability could still work with the fallback/default pathway. Otherwise, we'd need to expose some sysfs node as you mentioned in the other reply, for libvirt to set or hide a "vcmdq" option. Thanks Nicolin
