[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 04/18] xen/pvcalls: xenbus state handling
Many thanks for all the reviews! On Tue, 4 Jul 2017, Juergen Gross wrote: > On 03/07/17 23:08, Stefano Stabellini wrote: > > Introduce the code to handle xenbus state changes. > > > > Implement the probe function for the pvcalls backend. Write the > > supported versions, max-page-order and function-calls nodes to xenstore, > > as required by the protocol. > > > > Introduce stub functions for disconnecting/connecting to a frontend. > > > > Signed-off-by: Stefano Stabellini <stefano@xxxxxxxxxxx> > > Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> > > CC: boris.ostrovsky@xxxxxxxxxx > > CC: jgross@xxxxxxxx > > --- > > drivers/xen/pvcalls-back.c | 152 > > +++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 152 insertions(+) > > > > diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c > > index 9044cf2..7bce750 100644 > > --- a/drivers/xen/pvcalls-back.c > > +++ b/drivers/xen/pvcalls-back.c > > @@ -25,20 +25,172 @@ > > #include <xen/xenbus.h> > > #include <xen/interface/io/pvcalls.h> > > > > +#define PVCALLS_VERSIONS "1" > > +#define MAX_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER > > + > > struct pvcalls_back_global { > > struct list_head frontends; > > struct semaphore frontends_lock; > > } pvcalls_back_global; > > > > +static int backend_connect(struct xenbus_device *dev) > > +{ > > + return 0; > > +} > > + > > +static int backend_disconnect(struct xenbus_device *dev) > > +{ > > + return 0; > > +} > > + > > static int pvcalls_back_probe(struct xenbus_device *dev, > > const struct xenbus_device_id *id) > > { > > + int err, abort; > > + struct xenbus_transaction xbt; > > + > > +again: > > + abort = 1; > > + > > + err = xenbus_transaction_start(&xbt); > > + if (err) { > > + pr_warn("%s cannot create xenstore transaction\n", __func__); > > + return err; > > + } > > + > > + err = xenbus_printf(xbt, dev->nodename, "versions", "%s", > > + PVCALLS_VERSIONS); > > + if (err) { > > + pr_warn("%s write out 'version' failed\n", __func__); > > s/version/versions/ ? OK > > + goto abort; > > + } > > + > > + err = xenbus_printf(xbt, dev->nodename, "max-page-order", "%u", > > + MAX_RING_ORDER); > > + if (err) { > > + pr_warn("%s write out 'max-page-order' failed\n", __func__); > > + goto abort; > > + } > > + > > + err = xenbus_printf(xbt, dev->nodename, "function-calls", > > + XENBUS_FUNCTIONS_CALLS); > > + if (err) { > > + pr_warn("%s write out 'function-calls' failed\n", __func__); > > + goto abort; > > + } > > + > > + abort = 0; > > +abort: > > + err = xenbus_transaction_end(xbt, abort); > > + if (err) { > > + if (err == -EAGAIN && !abort) > > Hmm, while I don't think xenbus_transaction_end() will ever > return -EAGAIN in the abort case I'm not sure you should limit > the retry loop to the non-abort case. Realistically, if we want to abort and get -EAGAIN, the best thing to do is to get out (current behavior). The other option would be to keep issuing xenbus_transaction_end(xbr, 1) in a loop until it succeeds, but it seems more fragile to me. > > + goto again; > > + pr_warn("%s cannot complete xenstore transaction\n", __func__); > > + return err; > > + } > > + > > + xenbus_switch_state(dev, XenbusStateInitWait); > > I don't think you should switch state in case of abort set, no? Good point, I'll change that. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |