> From: Paolo Bonzini <pbonzini@xxxxxxxxxx> > Sent: Wednesday, October 27, 2021 6:32 PM > > On 27/10/21 08:18, Tian, Kevin wrote: > >> I absolutely do *not* want an API that tells KVM to enable WBINVD. This > >> is not up for discussion. > >> > >> But really, let's stop calling the file descriptor a security proof or a > >> capability. It's overkill; all that we are doing here is kernel > >> acceleration of the WBINVD ioctl. > >> > >> As a thought experiment, let's consider what would happen if wbinvd > >> caused an unconditional exit from guest to userspace. Userspace would > >> react by invoking the ioctl on the ioasid. The proposed functionality > >> is just an acceleration of this same thing, avoiding the > >> guest->KVM->userspace->IOASID->wbinvd trip. > > > > While the concept here makes sense, in reality implementing a wbinvd > > ioctl for userspace requiring iommufd (previous /dev/ioasid is renamed > > to /dev/iommu now) to track dirty CPUs that a given process has been > > running since wbinvd only flushes local cache. > > > > Is it ok to omit the actual wbinvd ioctl here and just leverage vfio-kvm > > contract to manage whether guest wbinvd is emulated as no-op? > > Yes, it'd be okay for me. As I wrote in the message, the concept of a > wbinvd ioctl is mostly important as a thought experiment for what is > security sensitive and what is not. If a wbinvd ioctl would not be > privileged on the iommufd, then WBINVD is not considered privileged in a > guest either. > > That does not imply a requirement to implement the wbinvd ioctl, though. > Of course, non-KVM usage of iommufd systems/devices with non-coherent > DMA would be less useful; but that's already the case for VFIO. Thanks for confirming it! > > > btw does kvm community set a strict criteria that any operation that > > the guest can do must be first carried in host uAPI first? In concept > > KVM deals with ISA-level to cover both guest kernel and guest user > > while host uAPI is only for host user. Introducing new uAPIs to allow > > host user doing whatever guest kernel can do sounds ideal, but not > > exactly necessary imho. > > I agree; however, it's the right mindset in my opinion because > virtualization (in a perfect world) should not be a way to give > processes privilege to do something that they cannot do. If it does, > it's usually a good idea to ask yourself "should this functionality be > accessible outside KVM too?". > Agree. It's always good to keep such mindset in thought practice. Thanks Kevin
