[lkml]   [2019]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 09/16] xen/evtchn: support evtchn in xenhost_t
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/

> 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.


> Juergen

 \ /
  Last update: 2019-06-17 08:10    [W:0.058 / U:6.080 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site