On Fri, Jun 04, 2021 at 05:57:19PM +0200, Paolo Bonzini wrote: > On 04/06/21 17:50, Jason Gunthorpe wrote: > > > 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). > > Really the question to answer is what "security proof" do you want > > before the wbinvd can be enabled > > I don't want a security proof myself; I want to trust VFIO to make the right > judgment and I'm happy to defer to it (via the KVM-VFIO device). > > Given how KVM is just a device driver inside Linux, VMs should be a slightly > more roundabout way to do stuff that is accessible to bare metal; not a way > to gain extra privilege. Okay, fine, lets turn the question on its head then. VFIO should provide a IOCTL VFIO_EXECUTE_WBINVD so that userspace VFIO application can make use of no-snoop optimizations. The ability of KVM to execute wbinvd should be tied to the ability of that IOCTL to run in a normal process context. So, under what conditions do we want to allow VFIO to giave a process elevated access to the CPU: > > 1) User has access to a device that can issue no-snoop TLPS > > 2) User has access to an IOMMU that can not block no-snoop (today) > > 3) Require CAP_SYS_RAW_IO > > 4) Anyone Jason
