Re: [RFC PATCH v2 03/20] hw/arm/smmuv3-accel: Add initial infrastructure for smmuv3-accel device

[Nicolin Chen <nicolinc@nvidia.com>]

On Mon, Mar 17, 2025 at 07:07:52PM +0100, Eric Auger wrote:
> On 3/17/25 6:54 PM, Nicolin Chen wrote:
> > On Wed, Mar 12, 2025 at 04:15:10PM +0100, Eric Auger wrote:
> >> On 3/11/25 3:10 PM, Shameer Kolothum wrote:
> >>> Based on SMMUv3 as a parent device, add a user-creatable smmuv3-accel
> >>> device. In order to support vfio-pci dev assignment with a Guest
> >> guest
> >>> SMMUv3, the physical SMMUv3 has to be configured in nested(S1+s2)
> >> nested (s1+s2)
> >>> mode, with Guest owning the S1 page tables. Subsequent patches will
> >> the guest
> >>> add support for smmuv3-accel to provide this.
> >> Can't this -accel smmu also works with emulated devices? Do we want an
> >> exclusive usage?
> > Is there any benefit from emulated devices working in the HW-
> > accelerated nested translation mode?
> 
> Not really but do we have any justification for using different device
> name in accel mode? I am not even sure that accel option is really
> needed. Ideally the qemu device should be able to detect it is
> protecting a VFIO device, in which case it shall check whether nested is
> supported by host SMMU and then automatically turn accel mode?
> 
> I gave the example of the vfio device which has different class
> implementration depending on the iommufd option being set or not.

Do you mean that we should just create a regular smmuv3 device and
let a VFIO device to turn on this smmuv3's accel mode depending on
its LEGACY/IOMMUFD class?

Another question: how does an emulated device work with a vSMMUv3?
I could imagine that all the accel steps would be bypassed since
!sdev->idev. Yet, the emulated iotlb should cache its translation
so we will need to flush the iotlb, which will increase complexity
as the TLBI command dispatching function will need to be aware what
ASID is for emulated device and what is for vfio device..

Thanks
Nicolin