All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] shutdown.c - halt_action
@ 2006-11-03 21:29 Ben Thomas
  2006-11-04  7:46 ` Keir Fraser
  0 siblings, 1 reply; 4+ messages in thread
From: Ben Thomas @ 2006-11-03 21:29 UTC (permalink / raw)
  To: xen-devel

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

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)

-- 
------------------------------------------------------------------------
Ben Thomas                                         Virtual Iron Software
bthomas@virtualiron.com                            Tower 1, Floor 2
978-849-1214                                       900 Chelmsford Street
                                                    Lowell, MA 01851

[-- Attachment #2: 10090-halt_action.patch --]
[-- Type: text/x-patch, Size: 2347 bytes --]

# 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 preserves is halt_action=halt
# and preserves existing behavior.
#
# Signed-off-by: Ben Thomas (ben@virtualiron.com)

Index: xen-unstable.hg/xen/arch/x86/shutdown.c
===================================================================
--- xen-unstable.hg.orig/xen/arch/x86/shutdown.c	2006-10-26 10:56:41.000000000 -0400
+++ xen-unstable.hg/xen/arch/x86/shutdown.c	2006-10-30 11:17:59.000000000 -0500
@@ -29,6 +29,29 @@
 static long no_idt[2];
 static int reboot_mode;
 
+void machine_restart(char * __unused);
+
+enum {HALT_ACTION_HALT, HALT_ACTION_REBOOT};
+static int halt_action = HALT_ACTION_HALT;
+static long halt_action_wait = 10;
+
+static void __init halt_action_set(char *str)
+{
+    if (strcmp(str, "halt") == 0)
+        halt_action = HALT_ACTION_HALT;
+     else if (strncmp(str, "reboot", strlen("reboot")) == 0)
+    {
+        halt_action = HALT_ACTION_REBOOT;
+	str += strlen("reboot");
+	if (*str == ':')
+	  halt_action_wait = simple_strtol(++str, NULL, 10);
+	else
+	  halt_action_wait = 10;
+    } else
+        printk("halt_action '%s' not recognized", str);
+}
+custom_param("halt_action", halt_action_set);
+
 static inline void kb_wait(void)
 {
     int i;
@@ -48,6 +71,19 @@
 {
     watchdog_disable();
     console_start_sync();
+    if (halt_action != HALT_ACTION_HALT)
+    {
+    	printk("%s - reboot requested\n", __FUNCTION__);
+	halt_action = HALT_ACTION_HALT;		// We may end up back here - don't loop
+	if (halt_action_wait > 0)
+	{
+	    printk("%s - delay %ld seconds before reboot...\n", __FUNCTION__, halt_action_wait);
+	    mdelay(halt_action_wait * 1000);
+	}
+    	printk("%s - rebooting...\n", __FUNCTION__);
+	machine_restart(0);
+	// We shouldn't get back here, but if we do just halt
+    }
     smp_call_function(__machine_halt, NULL, 1, 0);
     __machine_halt(NULL);
 }

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] shutdown.c - halt_action
  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
  0 siblings, 1 reply; 4+ messages in thread
From: Keir Fraser @ 2006-11-04  7:46 UTC (permalink / raw)
  To: Ben Thomas, xen-devel

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] shutdown.c - halt_action
  2006-11-04  7:46 ` Keir Fraser
@ 2006-11-06 22:06   ` Ben Thomas
  2006-11-06 22:16     ` Keir Fraser
  0 siblings, 1 reply; 4+ messages in thread
From: Ben Thomas @ 2006-11-06 22:06 UTC (permalink / raw)
  To: Keir Fraser; +Cc: 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] shutdown.c - halt_action
  2006-11-06 22:06   ` Ben Thomas
@ 2006-11-06 22:16     ` Keir Fraser
  0 siblings, 0 replies; 4+ messages in thread
From: Keir Fraser @ 2006-11-06 22:16 UTC (permalink / raw)
  To: Ben Thomas; +Cc: 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-11-06 22:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2006-11-06 22:16     ` Keir Fraser

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.