On Thu, Feb 15, 2024, Anish Moorthy wrote:
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 9f5d45c49e36..bf7bc21d56ac 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -1353,6 +1353,7 @@ yet and must be cleared on entry.
> #define KVM_MEM_LOG_DIRTY_PAGES (1UL << 0)
> #define KVM_MEM_READONLY (1UL << 1)
> #define KVM_MEM_GUEST_MEMFD (1UL << 2)
> + #define KVM_MEM_EXIT_ON_MISSING (1UL << 3)
David M.,
Before this gets queued anywhere, a few questions related to the generic KVM
userfault stuff you're working on:
1. Do you anticipate reusing KVM_MEM_EXIT_ON_MISSING to communicate that a vCPU
should exit to userspace, even for guest_memfd? Or are you envisioning the
"data invalid" gfn attribute as being a superset?
We danced very close to this topic in the PUCK call, but I don't _think_ we
ever explicitly talked about whether or not KVM_MEM_EXIT_ON_MISSING would
effectively be obsoleted by a KVM_SET_MEMORY_ATTRIBUTES-based "invalid data"
flag.
I was originally thinking that KVM_MEM_EXIT_ON_MISSING would be re-used,
but after re-watching parts of the PUCK recording, e.g. about decoupling
KVM from userspace page tables, I suspect past me was wrong.
2. What is your best guess as to when KVM userfault patches will be available,
even if only in RFC form?
The reason I ask is because Oliver pointed out (off-list) that (a) Google is the
primary user for KVM_MEM_EXIT_ON_MISSING, possibly the _only_ user for the
forseeable future, and (b) if Google moves on to KVM userfault before ever
ingesting KVM_MEM_EXIT_ON_MISSING from upstream, then we'll have effectively
added dead code to KVM's eternal ABI.
