On 3/17/25 3:24 PM, Jason Gunthorpe wrote:
On Mon, Mar 17, 2025 at 12:10:19PM -0700, Nicolin Chen wrote:
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..
I think you should block it. We already expect different vSMMU's
... and when you say 'block', you mean qemu prints out a helpful message
like "Mixing emulate/virtual devices and physical devices on a single SMMUv3 is
not allowed.
Specify separate smmuv3 objects for each type of device; multiple smmuv3
objects may
be required for each physical device if they are attached to different
smmuv3's in the host system."
Or would that be an allowed qemu machine definition, but the 'block' would be a
warning like:
"Mixing emulated/virtual devices and physical devices on a single SMMUv3 is
not recommended for
performance reasons. To yield optimal performance, place physical devices on
separate SMMUv3 objects
than emulated/virtual device SMMUv3 objects."
... and in this case, the physical devices would not use the accel features of
an smmuv3, but still be 'functional'.
This may be desired for a machine definition that wants to be used on different
hosts that may not have the
(same) accel feature(s).
depending on the physical SMMU under the PCI device, it makes sense
that a SW VFIO device would have it's own, non-accelerated, vSMMU
model in the guest.
Jason
