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? > Is there any concern if iommufd also follows the same mechanism? > Currently looks preempt notifier is only used by kvm. Not sure whether > there is strong criteria around using it. and this local behavior may > not apply to all platforms (then better hidden behind arch callback?) I don't have any desire to see a performance cost to implement an ioctl that nothing will ever call just to satisify a idealized target from the kvm folks.. Jason
