All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yang, Xiaowei" <xiaowei.yang@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: HVM restart issue
Date: Thu, 12 Mar 2009 16:15:10 +0800	[thread overview]
Message-ID: <49B8C48E.902@intel.com> (raw)

Recently I found HVM restart (destroy + start) is very slowly and the 
reason is the change to xen-hotplug-cleanup (see below).

When HVM is destroyed, backend vbd/vnif drivers will not be notified 
until /local/domain/hvm_id is removed in xenstore. udev event is then 
generated and xen-hotplug-cleanup is called. So the first xenstore-read 
will always fail and leave rest undone and xenstore unclean. Suggestion 
is to move it after backend/frontend removal.

Another interesting thing is that in function claim_lock, "release_lock 
$1; sigerr" is registered as ERR handler. However it seems its scope in 
effect is within the function. After claim_lock returns, the handler 
restores to the previous one ("sigerr") on my machine. So when the above 
error happens, the first script exits without calling release_lock. It 
keeps the following script waiting. Is this a correct BASH behavior?

Thanks,
xiaowei

diff -r 16fc70ce40a7 -r b3774712e654 tools/hotplug/Linux/xen-hotplug-cleanup
--- a/tools/hotplug/Linux/xen-hotplug-cleanup   Mon Mar 02 10:32:32 2009 
+0000
+++ b/tools/hotplug/Linux/xen-hotplug-cleanup   Mon Mar 02 10:34:37 2009 
+0000
@@ -11,6 +11,13 @@ dir=$(dirname "$0")
  # This is pretty horrible, but there's not really a nicer way of 
solving this.
  claim_lock "block"

+# split backend/DEVCLASS/VMID/DEVID on slashes
+path_array=( ${XENBUS_PATH//\// } )
+# get /vm/UUID path
+vm=$(xenstore-read "/local/domain/${path_array[2]}/vm")
+# construct /vm/UUID/device/DEVCLASS/DEVID
+vm_dev="$vm/device/${path_array[1]}/${path_array[3]}"
+
  # remove device frontend store entries
  xenstore-rm -t \
    $(xenstore-read "$XENBUS_PATH/frontend" 2>/dev/null) 2>/dev/null || true
@@ -19,4 +26,7 @@ xenstore-rm -t "$XENBUS_PATH"        2>/
  xenstore-rm -t "$XENBUS_PATH"        2>/dev/null || true
  xenstore-rm -t "error/$XENBUS_PATH"  2>/dev/null || true

+# remove device path from /vm/UUID
+xenstore-rm -t "$vm_dev" 2>/dev/null || true
+
  release_lock "block"

             reply	other threads:[~2009-03-12  8:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12  8:15 Yang, Xiaowei [this message]
2009-03-12  8:31 ` HVM restart issue Keir Fraser
2009-03-12 10:56   ` Boris Derzhavets
2009-03-12 11:18     ` Keir Fraser
2009-03-12 13:02       ` Boris Derzhavets
2009-03-12 15:03         ` Keir Fraser
2009-03-12 15:10           ` Boris Derzhavets

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49B8C48E.902@intel.com \
    --to=xiaowei.yang@intel.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.