On Wed, Mar 19, 2025 at 07:09:33PM +0100, Eric Auger wrote: > > Option means something like this: > > -device smmuv3,accel=on > > instead of > > -device "smmuv3-accel" > > ? > > > > Yea, I think that's good.
> Yeah actually that's a big debate for not much. From an implementation > pov that shall not change much. The only doubt I have is if we need to > conditionnaly expose the MSI RESV regions it is easier to do if we > detect we have a smmuv3-accel. what the option allows is the auto mode. Mind elaborating your doubt about the MSI RESV region? Do you mean how VMS code should tag "accel=on" option and generate RMR nodes in the IORT table? > > We certainly can't do case (a): not all TLBI commands gives an "SID" > > field (so would have to broadcast, i.e. underlying SMMU HW would run > > commands that were supposed for emulated devices only); in case of > > vCMDQ, commands for emulated devices would be issued to real HW and > I am still confused about that. For instance if the guest sends an > NH_ASID, NH_VA invalidation and it happens both the emulated device and > VFIO-device share the same cd.asid (same guest iommu domain, which > practically should not happen) why shouldn't we propagate the > invalidation to the host. Does the problem come from the usage of vCMDQ > or would you foresee the same problem with a generic physical SMMU? Host (HW) would end up with executing commands that were issued for emulated devices, which impacts performance. With vCMDQ, QEMU cannot trap command queue because all invalidation commands will be issued to HW directly from the guest kernel driver. This includes TLBI and ATC_INV commands. It's probably okay to run TLBI commands with vCMDQ (again perf impact), while ATC_INV commands would result in "unkonwn SID" errors or directly ATC_INV timeouts. Thanks Nicolin
