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

[Xen-devel] Re: [Qemu-devel] [PATCH 01/11] Handle terminating signals.

To: qemu-devel@xxxxxxxxxx
Subject: [Xen-devel] Re: [Qemu-devel] [PATCH 01/11] Handle terminating signals.
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Mon, 11 Aug 2008 20:53:02 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 11 Aug 2008 18:54:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48A099ED.6050303@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1218457970-11707-1-git-send-email-kraxel@xxxxxxxxxx> <1218457970-11707-2-git-send-email-kraxel@xxxxxxxxxx> <48A0933D.5070108@xxxxxxxxxxxxx> <48A099ED.6050303@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.16 (X11/20080723)
Gerd Hoffmann wrote:
Anthony Liguori wrote:
Gerd Hoffmann wrote:
+void fatalsig_register_handler(void (*func)(void));
Unless I'm misreading, none of your patches seem to use this function. What are you adding this mechanism for?

The patch using that isn't fully polished yet for submission.  Sneak
preview is here:

http://kraxel.fedorapeople.org/patches/qemu-upstream/0015-xen-domain-builder.patch

Adds pv domain builder to qemu, so you can start pv xen guests using
qemu only.  In that case we'll want to destroy the guest domain when
qemu goes down because the xen management stack will not cleanup after us.

I was asking because I thought it may be something like this. An alternative to this signal handler stuff would be to fork() off a process with another end of a pipe. That process could just sit their waiting for eof and when eof was received, it could destroy the domain.

The main advantage of this approach is that it works in every possible circumstance. Even if the qemu process totally borks it's stack or tramples over memory in such a way as to render the signal handling code broken.

Regards,

Anthony Liguori

cheers,
  Gerd



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