WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] libxl: do not rely on guest to respond when forc

On Tue, 2011-03-08 at 14:56 +0000, Gianni Tedesco wrote:
> On Tue, 2011-03-08 at 14:41 +0000, Ian Campbell wrote:
> > On Tue, 2011-03-08 at 14:35 +0000, Gianni Tedesco wrote:
> > > On Tue, 2011-03-08 at 14:17 +0000, 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).
> > > 
> > > It's possible but I think it's unlikely. Generally the qemu hardware
> > > emulation works in discrete steps advancing the state machine. The
> > > xenstore watching bits work in pretty much the same way.
> > > 
> > > > > 
> > > > > >              if (libxl__wait_for_device_model(ctx, domid, 
> > > > > > "pci-removed", NULL, NULL) < 0) {
> > > > >                       && !force ) {
> > > > > 
> > > > > perhaps?
> > > > 
> > > > Did you mean "!force && libxl__wait..." iow you need the !force to
> > > > short-circuit the waiting which was the point of the patch.
> > > 
> > > No, I meant to do the wait first but just not whinge about it if it
> > > times out. But the other way could make sense too, I'll get to that.
> > 
> > The wait and the timeout are the specific issue I am trying to address.
> > When I type "xl destroy foo" I expect domain foo to get shot in the head
> > right now, no questions and no hanging around. Similarly if I do "xl
> > pci-detach --force...".
> 
> OK, fair enough. Honestly, I think my expectation for the detach case to
> be more as I stated, but I don't feel strongly about it and it would
> just add complexity to have it that way.

That's the non--force'd way of doing it and AFAICT it behaves pretty
much as you describe.

Ian.



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