On Tue, 15 Feb 2022 11:03:59 +0000, Alexandru Elisei <alexandru.elisei@xxxxxxx> wrote: > > > If a memslot with read/write permission is locked with read only, > > and then unlocked, can userspace expect stage 2 mapping for the > > memslot to be updated with read/write ? > > Locking a memslot with the read flag would map the memory described by the > memslot with read permissions at stage 2. When the memslot is unlocked, KVM > won't touch the stage 2 entries. > > When the memslot is unlocked, the pages (as in, struct page) backing the VM > memory as described by the memslot are unpinned. Then the host's MM subsystem > can treat the memory like any other pages (make them old, new, unmap them, do > nothing, etc), and the MMU notifier will take care of updating the stage 2 > entries as necessary. > > I guess I should have been more precise in the description. I'll > change "causes the memory pinned when locking the memslot specified > in args[0] to be unpinned" to something that clearly states that the > memory in the host that backs the memslot is unpinned. > > > Can userspace delete the memslot that is locked (without unlocking) ? > > No, it cannot. > > > If so, userspace can expect the corresponding range to be implicitly > > unlocked, correct ? > > Userspace must explicitely unlock the memslot before deleting it. I want > userspace to be explicit in its intent. Does it get in the way of making this robust wrt userspace being killed (or terminating without unlock first)? M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
