> -----Original Message-----
> From: Nicolin Chen <[email protected]>
> Sent: Monday, March 17, 2025 8:19 PM
> To: Jason Gunthorpe <[email protected]>
> Cc: Eric Auger <[email protected]>; Shameerali Kolothum Thodi
> <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; Linuxarm <[email protected]>; Wangzhou (B)
> <[email protected]>; jiangkunkun <[email protected]>;
> Jonathan Cameron <[email protected]>;
> [email protected]
> Subject: Re: [RFC PATCH v2 03/20] hw/arm/smmuv3-accel: Add initial
> infrastructure for smmuv3-accel device
> 
> On Mon, Mar 17, 2025 at 04:24:53PM -0300, 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
> > 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.
> 
> Yea, I agree and it'd be cleaner for an implementation separating
> them.
> 
> In my mind, the general idea of "accel=on" is also to keep things
> in a more efficient way: passthrough devices go to HW-accelerated
> vSMMUs (separated PCIE buses), while emulated ones go to a vSMMU-
> bypassed (PCIE0).
> 
> Though I do see the point from QEMU prospective that user may want
> to start a VM with HW-accelerated vSMMU for one passthrough device
> using a simple setup without caring about the routing via command.

For now we don't use iotlb for accel cases with emulated devices. So probably
can document/warn the user about possible performance degradation if they
attach such a device rather than blocking.

Thanks,
Shameer
 

Reply via email to