lkml.org 
[lkml]   [2023]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [RFC PATCH v12 07/33] KVM: Add KVM_EXIT_MEMORY_FAULT exit to report faults to userspace
    From
    On Fri, Sep 22, 2023, Xiaoyao Li wrote:
    > On 9/14/2023 9:55 AM, Sean Christopherson wrote:
    > > From: Chao Peng <chao.p.peng@linux.intel.com>
    > >
    > > 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 :-)

    \
     
     \ /
      Last update: 2023-09-22 16:31    [W:4.458 / U:1.932 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site