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/
Home Products Support Community News


Re: [Xen-devel] [PATCH] - add symmetry to para and fully virtualized dom

To: Ben Thomas <bthomas@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] - add symmetry to para and fully virtualized domain shutdown/reboot
From: Edwin Zhai <edwin.zhai@xxxxxxxxx>
Date: Tue, 4 Apr 2006 23:15:59 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 04 Apr 2006 08:18:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <443145FF.5050800@xxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <443145FF.5050800@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.11

your patch is reasonable.

as my understanding, destroy is totally different from shutdown. destroy just 
issues a hyper-call(DOM0_OP), while shutdown writes xenstore and waits the 
handling almost everything( use sched_op hypercall for itself).

so, qemu's destroy command(kill hvm dom immediately when hang) should use the 
original destroy hyper-call to take place of "xm destroy".

On Mon, Apr 03, 2006 at 11:57:51AM -0400, Ben Thomas wrote:
> Add code to make handling domain poweroff/reboot symmetrical
> between paravirtualized and fully virtualized.
> A paravirtualized domain uses sched_op to shut down and set the
> reason code. This will send a VIRQ_DOM_EXC, which can be
> handled in dom0 by control software.  In some ways, this resembles
> SIGCHILD/waitpid, and is a reasonable model.
> The fully virtualized case has qemu invoke xm directly. This is a
> different path than paravirtualized. It also removes
> decision and policy making choices from the rest of the control
> software and places it within qemu. When any dom0 logic
> eventually gets a VIRQ_DOM_EXC, the information about the
> domain is gone having been destroyed by xm.
> It would be useful if all shutdown/reboot operations were
> symmetrical from domain 0's point of view. One approach
> would be to redefine sched_op to handle other domains than
> the current domain, but this seemed excessive. Another
> approach, which is what this patch implements, adds
> a DOM0 hypervisor call very similar to the existing
> the shutdown and reason -- basically, just like a
> paravirtualized system.
> Like DOM0_DESTROYDOMAIN, add a xenctrl wrapper, and have qemu
> call it.
> With this change, both domain types shutdown/reboot using
> the same dom0 management logic. All control decisions are
> removed from qemu, which now simply handles the request
> and reason. At a very high level, the flow is "notify of
> shutdown and reason", "send VIRQ_DOM_EXC", process, and
> destroy domain.  Paravirtualized and fully-virtualized
> domains would differ slightly in the first step of
> notification.  Paravirtualized continues to use sched_op,
> fully virtualized uses DOM0_SHUTDOWNDOMAIN. The rest
> of the steps would be identical in both cases.
> Or, back to the opening sentence, make the operations as
> symmetrical as possible.
> (As a freebie, #if 0 some very verbose logging code in qemu.
>  Totally unrelated, but as long as I was there...)
> Signed-off-by: Ben Thomas (ben@xxxxxxxxxxxxxxx)
> -- 
> ------------------------------------------------------------------------
> Ben Thomas                                         Virtual Iron Software
> bthomas@xxxxxxxxxxxxxxx                            Tower 1, Floor 2
> 978-849-1214                                       900 Chelmsford Street
>                                                    Lowell, MA 01851

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


Xen-devel mailing list