[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 11/22] vixen: early initialization of Vixen including shared_info mapping



On Sun, Jan 07, 2018 at 07:33:06AM -0800, Anthony Liguori wrote:
> On Sun, Jan 7, 2018 at 12:23 AM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> > On Sat, Jan 06, 2018 at 02:54:26PM -0800, Anthony Liguori wrote:
> >> From: Anthony Liguori <aliguori@xxxxxxxxxx>
> >> +    rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> >> +    if ( rc < 0 )
> >> +        printk("Setting shared info page failed: %ld\n", rc);
> >> +
> >> +    memset(&global_si->native.evtchn_mask[0], 0x00,
> >> +           sizeof(global_si->native.evtchn_mask));
> >
> > Hm, I'm not sure I like to approach of unmasking everything. IMHO I
> > would rather mask everything and unmask them when the guest actually
> > binds the event channel. That makes sure that an interrupt will get
> > injected when the event channel is unmasked (if there's an event
> > pending).
> 
> This is done in hvmloader and we discovered that guests rely on it.
> See hvmloader/xenbus.c:xenbus_shutdown().

But that's something completely different. There hvmloader is
resetting everything so the guest finds it in a proper state
(hvmloader is handling the shared_info page to the guest kernel). Here
vixen is not sharing the shared_info page with the guest (this is
just used by vixen), and hence I would do the opposite: mask
everything and unmask the event channels that the guest is actually
using.

Roger.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.