On Tue, Mar 18, 2025 at 05:22:51PM -0400, Donald Dutile wrote: > I agree with Eric that 'accel' isn't needed -- this should be > ascertained from the pSMMU that a physical device is attached to.
I seem to remember the point was made that we don't actually know if accel is possible, or desired, especially in the case of hotplug. The accelerated mode has a number of limitations that the software mode does not have. I think it does make sense that the user would deliberately choose to use a more restrictive operating mode and then would have to meet the requirements - eg by creating the required number and configuration of vSMMUs. > Now... how does vfio(?; why not qemu?) layer determine that? -- > where are SMMUv3 'accel' features exposed either: a) in the device > struct (for the smmuv3) or (b) somewhere under sysfs? ... I couldn't > find anything under either on my g-h system, but would appreciate a > ptr if there is. I think it is not discoverable yet other thatn through try-and-fail. Discoverability would probably be some bits in an iommufd GET_INFO ioctl or something like that. > and like Eric, although 'accel' is better than the > original 'nested', it's non-obvious what accel feature(s) are being > turned on, or not. There are really only one accel feature - direct HW usage of the IO Page table in the guest (no shadowing). A secondary addon would be direct HW usage of an invalidation queue in the guest. > kernel boot-param will be needed; if in sysfs, a write to 0 an > enable(disable) it maybe an alternative as well. Bottom line: we > need a way to (a) ascertain the accel feature (b) a way to disable > it when it is broken, so qemu's smmuv3 spec will 'just work'. You'd turned it off by not asking qemu to use it, that is sort of the reasoning behind the command line opt in for accel or not. Jason
