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

Re: [Xen-devel] [PATCH 1/2] libxl: Wait until QEMU removed the device before tearing it down



Boris Ostrovsky writes ("Re: [PATCH 1/2] libxl: Wait until QEMU removed the 
device before tearing it down"):
> On 11/14/2014 11:19 AM, Ian Jackson wrote:
> > The most seriouis is this: you may not call usleep() anywhere inside
> > libxl.  If you want to wait, you must use the callback mechanisms.
> 
> There are already instances of usleep in libxl

Yes.  :-/.

> (e.g. qmp_open(), which is where I got the ~5 seconds number,
> btw). But I agree that callbacks are better here, I didn't think of
> non-xl users.

Right.  In this case the polling loop is worse than in qmp_open,
because a guest which doesn't respond to the pci event can trivially
cause the process to lock up.  (Causing qemu to fail to respond in a
timely fashion is probably possible but harder.)

> > I think that this means:
> >    * [asyncinfying]
> 
> OK, I'll try to see what needs to be done (I am not familiar with how 
> libxl does asynchronous calls)

Thanks.  You probably want to read the CODING_STYLE patch series that
I posted recently.  There are some examples of how to do event
chaining in the domain creation, bootloader execution and disk/vif
handling.

> > Secondly, I'm not particularly keen on polling. Is there not a QMP
> > function that can be used to get notified when the device is really
> > removed ?
> 
> I didn't see any.

Oh well.

> > Finally, some notes about error handling:
...
> > rc must contain only libxl error values.  Most libxl functions return
> > libxl error values, not errno values.
> 
> rc is overwritten later:

I didn't spot that.

> So this whole rc assignment business in the patch was somewhat pointless 
> anyway.

Ah well.

> One question though: should we fail on the timeout and not clean up 
> xenstore and reset the device (which is what this version of the patch 
> does)? Because we may end up with device finally removed and cleanup up 
> by QEMU/guest but not reset and removed from xenstore.

This is a bit of a policy decision.  My initial view is that if the
guest fails to respond to the unplug request, we should just force the
unplug and the guest will have to live with the resulting damage.

At the very least, it must be possible to tear the whole thing down
properly when destroying the domain.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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