Mailing List Archive

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



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

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

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

On 6/11/06 10:06 pm, "Ben Thomas" <bthomas@virtualiron.com> wrote:

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

That's basically what I checked in a few days ago. It may only just have hit
the public tree as network connectivity issues have stalled the usual
automatic pushes from the staging tree.

-- Keir



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