Hey, Thanks Sean for bringing this up on the list, didn't have time for a lot of upstream stuffs :) On Fri, Mar 08, 2024 at 04:46:32PM -0800, David Matlack wrote: > On 2024-03-08 02:07 PM, Sean Christopherson wrote: > > 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. > > No I don't anticipate reusing KVM_MEM_EXIT_ON_MISSING. > > The plan is to introduce a new gfn attribute and exit to userspace based > on that. I do forsee having an on/off switch for the new attribute, but > it wouldn't make sense to reuse KVM_MEM_EXIT_ON_MISSING for that. With that in mind, unless someone else has a usecase for the KVM_MEM_EXIT_ON_MISSING behavior my *strong* preference is that we not take this bit of the series upstream. The "memory fault" UAPI should still be useful when the KVM userfault stuff comes along. Anish, apologies, you must have whiplash from all the bikeshedding, nitpicking, and other fun you've been put through on this series. Thanks for being patient. > > > > 2. What is your best guess as to when KVM userfault patches will be available, > > even if only in RFC form? > > We're aiming for the end of April for RFC with KVM/ARM support. Just to make sure everyone is read in on what this entails -- is this the implementation that only worries about vCPUs touching non-present memory, leaving the question of other UAPIs that consume guest memory (e.g. GIC/ITS table save/restore) up for further discussion? -- Thanks, Oliver
