On Wed, Feb 07, 2024, Anish Moorthy wrote: > On Wed, Feb 7, 2024 at 8:41 AM Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > > > On Wed, Feb 07, 2024 at 07:39:50AM -0800, Sean Christopherson wrote: > > > > Having said that... > > > > > be part of this patch. Because otherwise, advertising KVM_CAP_MEMORY_FAULT_INFO > > > is a lie. Userspace can't catch KVM in the lie, but that doesn't make it right. > > > > > > That should in turn make it easier to write a useful changelog. > > > > The feedback still stands. The capability needs to be squashed into the > > patch that actually introduces the functionality. > > > > -- > > Thanks, > > Oliver > > Hold on, I think there may be confusion here. > KVM_CAP_MEMORY_FAULT_INFO is the mechanism for reporting annotated > EFAULTs. These are generic in that other things (such as the guest > memfd stuff) may also report information to userspace using annotated > EFAULTs. > > KVM_CAP_EXIT_ON_MISSING is the thing that says "do an annotated EFAULT > when a stage-2 violation would require faulting in host mapping" On > both x86 and arm64, the relevant functionality is added and the cap is > advertised in a single patch. > > I think it makes sense to enable/advertise the two caps separately (as > I've done here). The former, after all, just says that userspace "may > get annotated EFAULTs for whatever reason" (as opposed to the latter > cap, which says that userspace *will* get annotated EFAULTs when the > stage-2 handler is failed). So even if arm64 userspaces never get > annotated EFAULTs as of this patch, I don't think we're "lying" to > them. Neither Oliver nor I are advocating you smush the two together. We're saying the code that actually fills memory_fault should be either (a) a separate patch (x86) or (b) in the patch that advertises KVM_CAP_MEMORY_FAULT_INFO (arm). I *highly* doubt it will matter in practice, but if there was a problem with filling memory_fault, it would be nice to isolate that to a standalone patch, and not the EXIT_ON_MISSING_CHANGE.
