lkml.org 
[lkml]   [2020]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH RFC 11/39] KVM: x86/xen: evtchn signaling via eventfd
    From
    Date
    On 11/30/20 9:41 AM, David Woodhouse wrote:
    > On Wed, 2019-02-20 at 20:15 +0000, Joao Martins wrote:
    >> userspace registers a @port to an @eventfd, that is bound to a
    >> @vcpu. This information is then used when the guest does an
    >> EVTCHNOP_send with a port registered with the kernel.
    >
    > Why do I want this part?
    >
    It is unnecessary churn to support eventfd at this point.

    The patch subject/name is also a tad misleading, as
    it implements the event channel port offloading with the optional fd
    being just a small detail in addition.

    >> EVTCHNOP_send short-circuiting happens by marking the event as pending
    >> in the shared info and vcpu info pages and doing the upcall. For IPIs
    >> and interdomain event channels, we do the upcall on the assigned vcpu.
    >
    > This part I understand, 'peeking' at the EVTCHNOP_send hypercall so
    > that we can short-circuit IPI delivery without it having to bounce
    > through userspace.
    >
    > But why would I then want then short-circuit the short-circuit,
    > providing an eventfd for it to signal... so that I can then just
    > receive the event in userspace in a *different* form to the original
    > hypercall exit I would have got?
    >

    One thing I didn't quite do at the time, is the whitelisting of unregistered
    ports to userspace. Right now, it's a blacklist i.e. if it's not handled in
    the kernel (IPIs, timer vIRQ, etc) it goes back to userspace. When the only
    ones which go to userspace should be explicitly requested as such
    and otherwise return -ENOENT in the hypercall.

    Perhaps eventfd could be a way to express this? Like if you register
    without an eventfd it's offloaded, otherwise it's assigned to userspace,
    or if neither it's then returned an error without bothering the VMM.

    But still, eventfd is probably unnecessary complexity when another @type
    (XEN_EVTCHN_TYPE_USER) would serve, and then just exiting to userspace
    and let it route its evtchn port handling to the its own I/O handling thread.

    Joao

    \
     
     \ /
      Last update: 2020-11-30 13:21    [W:4.515 / U:0.568 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site