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] shutdown.c - halt_action

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] shutdown.c - halt_action
From: Ben Thomas <bthomas@xxxxxxxxxxxxxxx>
Date: Mon, 06 Nov 2006 17:06:40 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 06 Nov 2006 14:07:07 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C171F5C1.3D2B%Keir.Fraser@xxxxxxxxxxxx>
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: <C171F5C1.3D2B%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501)
Hi Keir,

As always, there are alternatives to almost any issue. I had
considered just fixing up the instances (eg, #3 below), but
decided on an alternate approach for a few reasons.  I'll
spare you the reasoning, and jump to another proposal.

As you note, there are a few calls to machine_halt:

fatal_trap
do_double_fault

maybe_reboot (with opt_noreboot set)
panic (with opt_noreboot set)
dom0_shutdown (with poweroff requested)

This is the same list you mention below, and the last 3 items are
governed by a "switch", two of which would appear to default to
rebooting and one by specific request. So, let's assume that those
3 are ok.  What would you like done with fatal_trap and
do_double_fault ?  Should they be handled the same as panic and
maybe_reboot ? More specifically, perhaps fatal_trap, do_double_fault
and panic should just call maybe_reboot rather than machine_halt.
That keeps a common routine, which I like for reasons of maintenance
and defensiveness; it defaults to rebooting, but can be set to
halting; it builds off the exiting boot parameter. And, my real goal,
it allows the option of not halting. Unfortunately, it will change
some of the current behavior in that fatal_trap and do_double_fault
will now reboot and not halt.  Is that an acceptable difference ?

Does that more closely approximate what you'd like to see ?


Thanks,
-b


-
Keir Fraser wrote:
On 3/11/06 9:29 pm, "Ben Thomas" <bthomas@xxxxxxxxxxxxxxx> wrote:


It's not always desirable for a system to halt.  The hypervisor has a
number of places where it does request a halt, and this might be useful
for debugging, but not always in a production environment. Add a
hypervisor command line parameter, halt_action, which allows the
overriding of any halt requests.  The parameter takes the form of
halt_action=halt, halt_action=reboot or halt_action=reboot:20
for halting, rebooting after a default 10 seconds, or rebooting after
a specified number of seconds. The default is halt_action=halt
and preserves existing behavior.

Signed-off-by: Ben Thomas (ben@xxxxxxxxxxxxxxx)


We halt in three situations:
 1. Domain-0 asked us to (thru poweroff or halt)
 2. 'noreboot' was specified as a boot parameter
 3. We take an exception with IRQs disabled or we take a double fault.

Behaviours (1) and (2) are quite reasonable. We should really just fix (3)
to (attempt to) reboot after a few seconds, just like any other fatal
exception.

 -- Keir




--
------------------------------------------------------------------------
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

<Prev in Thread] Current Thread [Next in Thread>