On Wed, Sep 27, 2023, Binbin Wu wrote: > > On 9/22/2023 4:33 AM, Sean Christopherson wrote: > > Track the effects of private attributes on potential hugepage mappings if > > the VM supports private memory, i.e. even if the target memslot can only > > ever be mapped shared. If userspace configures a chunk of memory as > > private, KVM must not allow that memory to be mapped shared regardless of > > whether or not the *current* memslot can be mapped private. E.g. if the > > guest accesses a private range using a shared memslot, then KVM must exit > > to userspace. > How does usersapce handle this case? > IIRC, in gmem v12 patch set, it says a memslot can not be convert to private > from shared. > So, userspace should delete the old memslot and and a new one? That depends on the contract between userspace and the VM, e.g. if the access is to a range that the VMM and the guest have agreed is shared-only, then the VMM could also "resolve" the access by injecting an error or killing the VM. But yes, deleting the memslot and creating a new one is the only approach that will work if userspace wants to map the gfn as private. I don't actually expect any real world VMMs to actually do anything like this, the purpose of this change is mainly to ensure KVM has robust, consistent behavior.
