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

[Shameerali Kolothum Thodi via <qemu-arm@nongnu.org>]

> -----Original Message-----
> From: Donald Dutile <ddutile@redhat.com>
> Sent: Thursday, November 28, 2024 4:29 AM
> To: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; Nicolin Chen
> <nicolinc@nvidia.com>; Eric Auger <eric.auger@redhat.com>
> Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org;
> peter.maydell@linaro.org; jgg@nvidia.com; Linuxarm
> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>;
> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron
> <jonathan.cameron@huawei.com>; zhangfei.gao@linaro.org
> Subject: Re: [RFC PATCH 2/5] hw/arm/smmuv3: Add initial support for
> SMMUv3 Nested device
> 
> 
> >>> 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 \

Ok. But I think the initial suggestion to call this something else other than arm-smmuv3
came from the fact that it makes use of physical SMMUv3 nested stage support. This is
required for vfio-pci assignment. So I used "accel" in that context. That is what I
mean by basic functionality of this SMMUV3 device. If we need any additional accelerated
feature support then that can be provided as "properties" on top of this. Like,

- device arm-smmuv3-accel,id=smmu1,bus=pcie.1,vcmdq=on \

Or may be as Nicolin's suggestion(without explicit "vcmdq") of probing for vCMDQ
support transparently and falling back to basic support if not available.

I prefer the first one which gives an option to turn off if required. But don’t have any
strong opinion either way. 

Thanks,
Shameer.