> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Tuesday, October 26, 2021 7:35 AM > > On Fri, Oct 22, 2021 at 03:08:06AM +0000, Tian, Kevin wrote: > > > > I have no idea what security model makes sense for wbinvd, that is the > > > major question you have to answer. > > > > wbinvd flushes the entire cache in local cpu. It's more a performance > > isolation problem but nothing can prevent it once the user is allowed > > to call this ioctl. This is the main reason why wbinvd is a privileged > > instruction and is emulated by kvm as a nop unless an assigned device > > has no-snoop requirement. alternatively the user may call clflush > > which is unprivileged and can invalidate a specific cache line, though > > not efficient for flushing a big buffer. > > > > One tricky thing is that the process might be scheduled to different > > cpus between writing buffers and calling wbinvd ioctl. Since wbvind > > only has local behavior, it requires the ioctl to call wbinvd on all > > cpus that this process has previously been scheduled on. > > That is such a hassle, you may want to re-open this with the kvm > people as it seems ARM also has different behavior between VM and > process here. > > The ideal is already not being met, so maybe we can keep special > casing cache ops? > Now Paolo confirmed wbinvd ioctl is just a thought experiment. Then Jason, want to have a clarification on 'keep special casing' here. Did you mean adopting the vfio model which neither allows the user to decide no-snoop format nor provides a wbinvd ioctl for the user to manage buffers used for no-snoop traffic, or still wanting the user to decide no-snoop format but not implementing a wbinvd ioctl? The latter option sounds a bit incomplete from uAPI p.o.v. but it allows us to stay with one-format-one-ioas policy. And anyway the userspace can still call clflush to do cacheline-based invalidation, if necessary. The former option would force us to support multi-formats-one-ioas. either case it's iommufd which decides and tells kvm whether wbinvd is allowed for a process. Thanks Kevin
