From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sander Eikelenboom Subject: Re: xl shutdown --wait "racy" Date: Wed, 16 Apr 2014 16:55:55 +0200 Message-ID: <1596839466.20140416165555@eikelenboom.it> References: <415828617.20140416160821@eikelenboom.it> <1397657639.24638.193.camel@kazak.uk.xensource.com> <619165638.20140416162637@eikelenboom.it> <1397658810.24638.197.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1397658810.24638.197.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: George Dunlap , xen-devel , Ian Jackson List-Id: xen-devel@lists.xenproject.org Wednesday, April 16, 2014, 4:33:30 PM, you wrote: > On Wed, 2014-04-16 at 16:26 +0200, Sander Eikelenboom wrote: >> Wednesday, April 16, 2014, 4:13:59 PM, you wrote: >> >> > On Wed, 2014-04-16 at 16:08 +0200, Sander Eikelenboom wrote: >> >> Hi Ian (C|J) Konrad, >> >> >> >> I'm currently trying to workaround the pci-(detach|assignable-remove) issues i >> >> reported earlier. >> >> >> >> The workaround i thought of was: >> >> - shutting down the guest >> >> - starting it without 1 of the original devices passed through >> >> - use xl pci-assignable-remove and bind the device to the dom0 driver. >> >> >> >> But during this i noticed that a "xl shutdown --wait" does wait .. but returns: >> >> - Before the domain is removed from for instance "xl list", it still listed there in >> >> "--ps--" state. >> >> - before pciback has done it's restore config space magic. >> >> >> >> So it seems the wait loop is exiting somewhat prematurely, is this expected ? >> >> > It is waiting for the domain to be shutdown (state 's') not for the >> > domain to be destroyed. So it's doing what it said it would (I >> > appreciate you might not find this distinction helpful under the >> > circumstances...) >> >> It's at least not entirely what i expected ;-) >> >> Is it because there can be different "follow-up actions" due to the >> "on_poweroff=" config option ? > Not really, those are somewhat unrelated. > shutdown and destroy are two distinct events. Once a domain has shutdown > (called the shutdown hypercall etc) it goes into state "shutdown" and an > event is generated from the hypervisor to the toolstack. The toolstack's > response to this is to actually destroy the domain, that is to tear down > the resources it is using etc. > on_* only matter for the destroy phase since they tell the toolstack > what it should do (restart, preserve, really destroy etc). Hmm ok, it should be called "--wait_until_halfway" then ;-) On the more serious side .. would patches be accepted that: a) differentiate when it returns from waiting based on the on_* preserve: this could probably stay as is .. after the shutdown event destroy: restart: rename-restart: coredump-destroy: coredump-restart: for the other ones .. i don't know if there actually are events in libxl that could be 'easily' coupled ? b) make it possible for the xl commandline to overrule the on_* from the configfile c) also introduce a -w/--wait for xl destroy (with b and c, i could emulate "a" by doing a "xl shutdown -w preserve" followed by a "xl destroy -w". >> I can see the shutdown state would be the thing to wait for if it's configured >> with "preserve", but if it's configured with the default "destroy" i would >> expect it to wait until the guest is actually destroyed. The "restart" is perhaps >> somewhat more difficult, same goes for the coredump variants.