On 04/06/21 17:26, Alex Williamson wrote:
Let's make sure the KVM folks are part of this decision; a re-cap for them, KVM currently automatically enables wbinvd emulation when potentially non-coherent devices are present which is determined solely based on the IOMMU's (or platform's, as exposed via the IOMMU) ability to essentially force no-snoop transactions from a device to be cache coherent. This synchronization is triggered via the kvm-vfio device, where QEMU creates the device and adds/removes vfio group fd descriptors as an additionally layer to prevent the user from enabling wbinvd emulation on a whim. IIRC, this latter association was considered a security/DoS issue to prevent a malicious guest/userspace from creating a disproportionate system load. Where would KVM stand on allowing more direct userspace control of wbinvd behavior? Would arbitrary control be acceptable or should we continue to require it only in association to a device requiring it for correct operation.
Extending the scenarios where WBINVD is not a nop is not a problem for me. If possible I wouldn't mind keeping the existing kvm-vfio connection via the device, if only because then the decision remains in the VFIO camp (whose judgment I trust more than mine on this kind of issue).
For example, would it make sense if *VFIO* (not KVM) gets an API that says "I am going to do incoherent DMA"? Then that API causes WBINVD to become not-a-nop even on otherwise coherent platforms. (Would this make sense at all without a hypervisor that indirectly lets userspace execute WBINVD? Perhaps VFIO would benefit from a WBINVD ioctl too).
Paolo
