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
