[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [LINUX PATCH v3] xen: add support for initializing xenstore later as HVM domain
On Fri, 29 Apr 2022, Boris Ostrovsky wrote: > On 4/29/22 5:10 PM, Stefano Stabellini wrote: > > From: Luca Miccio <lucmiccio@xxxxxxxxx> > > > > When running as dom0less guest (HVM domain on ARM) the xenstore event > > channel is available at domain creation but the shared xenstore > > interface page only becomes available later on. > > > > In that case, wait for a notification on the xenstore event channel, > > then complete the xenstore initialization later, when the shared page > > is actually available. > > > > The xenstore page has few extra field. Add them to the shared struct. > > One of the field is "connection", when the connection is ready, it is > > zero. If the connection is not-zero, wait for a notification. > > > > Signed-off-by: Luca Miccio <lucmiccio@xxxxxxxxx> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx> > > CC: jgross@xxxxxxxx > > CC: boris.ostrovsky@xxxxxxxxxx > > --- > > Changes in v3: > > - check for the connection field, if it is not zero, wait for event > > > > Changes in v2: > > - remove XENFEAT_xenstore_late_init > > --- > > drivers/xen/xenbus/xenbus_probe.c | 86 +++++++++++++++++++++++------- > > include/xen/interface/io/xs_wire.h | 3 ++ > > 2 files changed, 70 insertions(+), 19 deletions(-) > > > > diff --git a/drivers/xen/xenbus/xenbus_probe.c > > b/drivers/xen/xenbus/xenbus_probe.c > > index fe360c33ce71..dc046d25789e 100644 > > --- a/drivers/xen/xenbus/xenbus_probe.c > > +++ b/drivers/xen/xenbus/xenbus_probe.c > > @@ -65,6 +65,7 @@ > > #include "xenbus.h" > > +static int xs_init_irq; > > int xen_store_evtchn; > > EXPORT_SYMBOL_GPL(xen_store_evtchn); > > @@ -750,6 +751,17 @@ static void xenbus_probe(void) > > { > > xenstored_ready = 1; > > + if (!xen_store_interface) { > > + xen_store_interface = xen_remap(xen_store_gfn << > > XEN_PAGE_SHIFT, > > + XEN_PAGE_SIZE); > > + /* > > + * Now it is safe to free the IRQ used for xenstore late > > + * initialization. No need to unbind: it is about to be > > + * bound again. > > > This assumes knowledge of bind/unbind internals. I think we should unbind. I gave it a try and there is a problem with unbinding the IRQ here. If I do that, later when xb_init_comms calls bind_evtchn_to_irqhandler, the event channel doesn't fire anymore. I did some testing and debugging and as far as I can tell the issue is that if we call unbind_from_irqhandler here, we end up calling xen_evtchn_close. Then, when xb_init_comms calls bind_evtchn_to_irqhandler on the same evtchn, it is not enough to receive event notifications anymore because from Xen POV the evtchn is "closed". If I comment out xen_evtchn_close() in __unbind_from_irq, then yes, I can call unbind_from_irqhandler here instead of free_irq and everything works. My suggestion is to keep the call to free_irq here (not unbind_from_irqhandler) and improve the in-code comment. > > + */ > > + free_irq(xs_init_irq, &xb_waitq); > > + } > > + > > > > > @@ -959,23 +988,42 @@ static int __init xenbus_init(void) > > * > > * Also recognize all bits set as an invalid value. > > > Is this comment still correct? I can improve the comment > > */ > > - if (!v || !~v) { > > + if (!v) { > > err = -ENOENT; > > goto out_error; > > } > > - /* Avoid truncation on 32-bit. */ > > + if (v == ~0ULL) { > > + wait = true; > > + } else { > > + /* Avoid truncation on 32-bit. */
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |