Re: [RFC PATCH 2/5] hw/arm/smmuv3: Add initial support for SMMUv3 Nested device

[Nicolin Chen <nicolinc@nvidia.com>]

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