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

[Eric Auger <eric.auger@redhat.com>]

Hi Jason,

On 3/19/25 1:31 AM, Jason Gunthorpe wrote:
> On Tue, Mar 18, 2025 at 07:31:36PM +0100, Eric Auger wrote:
>> Nevertheless I don't think anything prevents the acceleration granted
>> device from also working with virtio/vhost devices for instance unless
>> you unplug the existing infra.
> If the accel mode is using something like vcmdq then it is not
> possible to work since the invalidations won't even be trapped.

I acknowledged I was more focused on the case without vcmdq which was
addressed in the past and now I better see the problem.

>
> Even in the case where we trap the invalidations it sure is
> complicated.. invalidation is done by ASID which is not obviously
> related to any specific device. An ASID could be hidden inside a CD
> table that is being HW accessed and also inside a CD table that is SW
> accessed. The VMM has no way to know what is going on so you'd end up
> forced to replicate all the ASID invalidations. :\
Nevertheless I think we shall also support the case without vcmdq
(currently supported in this series). And this one looks more compatible
with emulated devices althout less optimized.

>
> It just doesn't seem worthwhile to try to make it all work.
>
> I'd suggest arranging to share some of the SMMUv3 emulation code,
> maybe with a library/headerfile or something, but I think it does make
> sense they would be different implementations given how completely
> different they should be.
I agree with can do our utmost to separate implementations. I more
concerned about having libvirt guessing what kind of devices it shall use.

on x86 libvirt needs to use -device intel-iommu,caching-mode=on if one
wants to protect a VFIO device. So this looks like similar to adding
accel=on on ARM.

Eric
>
> Jason
>