On Fri, Sep 22, 2023, Xiaoyao Li wrote: > On 9/14/2023 9:55 AM, Sean Christopherson wrote: > > From: Chao Peng <chao.p.peng@xxxxxxxxxxxxxxx> > > > > Add a new KVM exit type to allow userspace to handle memory faults that > > KVM cannot resolve, but that userspace *may* be able to handle (without > > terminating the guest). > > > > KVM will initially use KVM_EXIT_MEMORY_FAULT to report implicit > > conversions between private and shared memory. With guest private memory, > > there will be two kind of memory conversions: > > > > - explicit conversion: happens when the guest explicitly calls into KVM > > to map a range (as private or shared) > > > > - implicit conversion: happens when the guest attempts to access a gfn > > that is configured in the "wrong" state (private vs. shared) > > > > On x86 (first architecture to support guest private memory), explicit > > conversions will be reported via KVM_EXIT_HYPERCALL+KVM_HC_MAP_GPA_RANGE, > > side topic. > > Do we expect to integrate TDVMCALL(MAPGPA) of TDX into KVM_HC_MAP_GPA_RANGE? Yes, that's my expectation. > > but reporting KVM_EXIT_HYPERCALL for implicit conversions is undesriable > > as there is (obviously) no hypercall, and there is no guarantee that the > > guest actually intends to convert between private and shared, i.e. what > > KVM thinks is an implicit conversion "request" could actually be the > > result of a guest code bug. > > > > KVM_EXIT_MEMORY_FAULT will be used to report memory faults that appear to > > be implicit conversions. > > > > Place "struct memory_fault" in a second anonymous union so that filling > > memory_fault doesn't clobber state from other yet-to-be-fulfilled exits, > > and to provide additional information if KVM does NOT ultimately exit to > > userspace with KVM_EXIT_MEMORY_FAULT, e.g. if KVM suppresses (or worse, > > loses) the exit, as KVM often suppresses exits for memory failures that > > occur when accessing paravirt data structures. The initial usage for > > private memory will be all-or-nothing, but other features such as the > > proposed "userfault on missing mappings" support will use > > KVM_EXIT_MEMORY_FAULT for potentially _all_ guest memory accesses, i.e. > > will run afoul of KVM's various quirks. > > So when exit reason is KVM_EXIT_MEMORY_FAULT, how can we tell which field in > the first union is valid? > > When exit reason is not KVM_EXIT_MEMORY_FAULT, how can we know the info in > the second union run.memory is valid without a run.memory.valid field? I'll respond to this separately with a trimmed Cc list. I suspect this will be a rather lengthy conversation, and it has almost nothing to do with guest_memfd. > > +Note! KVM_EXIT_MEMORY_FAULT is unique among all KVM exit reasons in that it > > +accompanies a return code of '-1', not '0'! errno will always be set to EFAULT > > +or EHWPOISON when KVM exits with KVM_EXIT_MEMORY_FAULT, userspace should assume > > +kvm_run.exit_reason is stale/undefined for all other error numbers. > > + > > Initially, this section is the copy of struct kvm_run and had comments for > each field accordingly. Unfortunately, the consistence has not been well > maintained during the new filed being added. > > Do we expect to fix it? AFAIK, no one is working on cleaning up this section of the docs, but as always, patches are welcome :-)
