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

Re: [Xen-devel] [PATCH] libxl: do not rely on guest to respond when forcing pci device removal



On Tue, 2011-03-08 at 14:23 +0000, Stefano Stabellini wrote:
> On Tue, 8 Mar 2011, Ian Campbell wrote:
> > On Tue, 2011-03-08 at 12:56 +0000, Gianni Tedesco wrote:
> > > On Tue, 2011-03-08 at 11:49 +0000, Ian Campbell wrote:
> > > > # HG changeset patch
> > > > # User Ian Campbell <ian.campbell@xxxxxxxxxx>
> > > > # Date 1299584929 0
> > > > # Node ID 5084214b8983045d789a86c01e7a0fede46b5e58
> > > > # Parent  0e3211b5c4da98d170ed665c221bcb00e771fc56
> > > > libxl: do not rely on guest to respond when forcing pci device removal
> > > > 
> > > > This is consistent with the expected semantics of a forced device
> > > > removal and also avoids a delay when destroying an HVM domain which
> > > > either does not support hot unplug (does not respond to SCI) or has
> > > > crashed.
> > > > 
> > > > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > > > 
> > > > diff -r 0e3211b5c4da -r 5084214b8983 tools/libxl/libxl_pci.c
> > > > --- a/tools/libxl/libxl_pci.c   Tue Mar 08 11:13:12 2011 +0000
> > > > +++ b/tools/libxl/libxl_pci.c   Tue Mar 08 11:48:49 2011 +0000
> > > > @@ -866,7 +866,7 @@ static int do_pci_remove(libxl__gc *gc, 
> > > >  
> > > >          /* Remove all functions at once atomically by only signalling
> > > >           * device-model for function 0 */
> > > > -        if ( (pcidev->vdevfn & 0x7) == 0 ) {
> > > > +        if ( !force && (pcidev->vdevfn & 0x7) == 0 ) {
> > > >              xs_write(ctx->xsh, XBT_NULL, path, "pci-rem", 
> > > > strlen("pci-rem"));
> > > 
> > > Shouldn't we maybe send the pci-rem when force removing to give the
> > > guest a chance to do something if it can.
> > 
> > My concern was just that if this wasn't reacted to by qemu it might
> > interfere with us sending other requests in the future (I don't know and
> > haven't checked if that is the case).
> 
> The guest OS should be able to shutdown properly no matter if it
> receives the hot-unplug event or not.

Or it may have crashed.

> And Xen should be able to clean up the resources in use no matter if the
> guest OS handles the hot-unplug event or not.
> Therefore avoiding the hot-unplug code path on shutdown is perfectly
> reasonable.

Note that this change impacts the destroy path but not the shutdown
path.

Avoiding any need to do a graceful teardown is part of the point of the
difference between destroy and shutdown.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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