Re: [Xen-devel] [RFC PATCH 09/16] xen/evtchn: support evtchn in xenhost_t

[Ankur Arora <ankur.a.arora@xxxxxxxxxx>]

On 2019-06-14 5:04 a.m., Juergen Gross wrote:
> On 09.05.19 19:25, Ankur Arora wrote:
> > Largely mechanical patch that adds a new param, xenhost_t * to the
> > evtchn interfaces. The evtchn port instead of being domain unique, is
> > now scoped to xenhost_t.
> >
> > As part of upcall handling we now look at all the xenhosts and, for
> > evtchn_2l, the xenhost's shared_info and vcpu_info. Other than this
> > event handling is largley unchanged.
> >
> > Note that the IPI, timer, VIRQ, FUNCTION, PMU etc vectors remain
> > attached to xh_default. Only interdomain evtchns are allowable as
> > xh_remote.
> I'd do only the interface changes for now (including evtchn FIFO).
Looking at this patch again, it seems to me that it would be best to
limit the interface change (to take the xenhost_t * parameter) only to
bind_interdomain_*. That also happily limits the change to the drivers/
subtree.

> The main difference will be how to call the hypervisor for sending an
> event (either direct or via a passthrough-hypercall).
Yeah, though, this would depend on how the evtchns are mapped (if it's
the L1-Xen which is responsible for mapping the evtchn on behalf of the 
L0-Xen, then notify_remote_via_evtchn() could just stay the same.)
Still, I'll add a send interface (perhaps just an inline function) to
the xenhost interface for this.

Ankur

> Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel