On Sun, Mar 10, 2024, Oliver Upton wrote: > 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. +1 Though I'll go a step further and say that even if someone does have a use case, we should still wait. The imminent collision with David Steven's kvm_follow_pfn() series[*] is going to be a painful rebase no matter what, and once that's out of the way, rebasing this series onto future kernels shouldn't be crazy difficult. In other words, _if_ it turns out there's value in KVM_MEM_EXIT_ON_MISSING even with David M's work, the cost of waiting another cycle (or two) is relatively small. Oh, and I'll plan on grabbing patches 1-4 for 6.10. [*]https://lore.kernel.org/all/20240229025759.1187910-1-stevensd@xxxxxxxxxx
