From: Ben Thomas <bthomas@virtualiron.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] shutdown.c - halt_action
Date: Mon, 06 Nov 2006 17:06:40 -0500 [thread overview]
Message-ID: <454FB1F0.1040308@virtualiron.com> (raw)
In-Reply-To: <C171F5C1.3D2B%Keir.Fraser@cl.cam.ac.uk>
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@virtualiron.com> 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@virtualiron.com)
>
>
> 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@virtualiron.com Tower 1, Floor 2
978-849-1214 900 Chelmsford Street
Lowell, MA 01851
next prev parent reply other threads:[~2006-11-06 22:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-03 21:29 [PATCH] shutdown.c - halt_action Ben Thomas
2006-11-04 7:46 ` Keir Fraser
2006-11-06 22:06 ` Ben Thomas [this message]
2006-11-06 22:16 ` Keir Fraser
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=454FB1F0.1040308@virtualiron.com \
--to=bthomas@virtualiron.com \
--cc=Keir.Fraser@cl.cam.ac.uk \
--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.