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

[Nicolin Chen <nicolinc@nvidia.com>]

On Thu, Nov 28, 2024 at 08:54:26AM -0400, Jason Gunthorpe wrote:
> On Wed, Nov 27, 2024 at 08:44:47PM -0800, Nicolin Chen wrote:
> > 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.
> 
> It needs to be configurable so the VM can be configured in a
> consistent way across nodes
> 
> autodetection of host features is nice for experimenting but scale
> deployments should precisely specify every detail about the VM and not
> rely on host detection. Otherwise the VM instance type will be ill
> defined..

In that case, we'd need to expose a vcmdq capability somewhere.
We do for vIOMMU via hw_info. Should we keep the consistency?

Otherwise, some sysfs nodes (easier for libvirt) could do the
job too: num_available_vintfs, max_vcmdqs_per_vintf, and etc.

Thanks
Nicolin