On Tue, Jan 04, 2022 at 05:31:30PM +0000, Sean Christopherson wrote: > On Fri, Dec 31, 2021, Chao Peng wrote: > > On Fri, Dec 24, 2021 at 12:13:51PM +0800, Chao Peng wrote: > > > On Thu, Dec 23, 2021 at 06:06:19PM +0000, Sean Christopherson wrote: > > > > On Thu, Dec 23, 2021, Chao Peng wrote: > > > > > This new function establishes the mapping in KVM page tables for a > > > > > given gfn range. It can be used in the memory fallocate callback for > > > > > memfd based memory to establish the mapping for KVM secondary MMU when > > > > > the pages are allocated in the memory backend. > > > > > > > > NAK, under no circumstance should KVM install SPTEs in response to allocating > > > > memory in a file. The correct thing to do is to invalidate the gfn range > > > > associated with the newly mapped range, i.e. wipe out any shared SPTEs associated > > > > with the memslot. > > > > > > Right, thanks. > > > > BTW, I think the current fallocate() callback is just useless as long as > > we don't want to install KVM SPTEs in response to allocating memory in a > > file. The invalidation of the shared SPTEs should be notified through > > mmu_notifier of the shared memory backend, not memfd_notifier of the > > private memory backend. > > No, because the private fd is the final source of truth as to whether or not a > GPA is private, e.g. userspace may choose to not unmap the shared backing. > KVM's rule per Paolo's/this proposoal is that a GPA is private if it has a private > memslot and is present in the private backing store. And the other core rule is > that KVM must never map both the private and shared variants of a GPA into the > guest. That's true, but I'm wondering if zapping the shared variant can be handled at the time when the private one gets mapped in the KVM page fault. No bothering the backing store to dedicate a callback to tell KVM. Chao
