Shutdown questions / correct way of sending sysrq to Linux domains?

Shutdown questions / correct way of sending sysrq to Linux domains?

[Matthew Bloch]

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

Hi there,

I just wanted to check my approach before do a patch that the developers 
won't like the smell of.  I'm intending to create a method of sending 
emergency sysrqs from Domain 0 to other domains (patch so far attached).

This is a useful idea as it allows safe rescues of improperly setup 
guest systems, and could be a useful backstop for "xm shutdown" after a 
particular timeout (similar to what we do when we want to shut down a 
system full of recalcitrant user-mode linux processes that don't do the 
right thing on a ctrl+alt+delete).

Does the attached method make sense, i.e. commandeering CMSG_SHUTDOWN 
subtypes 33-127 to mean "call the sysrq handler"?  If so the only 
question is how to glue it into the user-space tools: "xm sysrq S" ?  or 
the counter-intuitive "xm shutdown --sysrq S"?  If the developers can 
state their preference I'll make a proper job of it.

cheers,

-- 
Matthew Bloch

[-- Attachment #2: sysrq-patch --]
[-- Type: text/plain, Size: 1805 bytes --]

diff -urN xen-2.0/xen/include/public/io/domain_controller.h xen-2.0-sysrq/xen/include/public/io/domain_controller.h
--- xen-2.0/xen/include/public/io/domain_controller.h	2004-11-17 22:51:47.000000000 +0000
+++ xen-2.0-sysrq/xen/include/public/io/domain_controller.h	2004-12-03 13:39:43.000000000 +0000
@@ -555,7 +555,8 @@
 #define CMSG_SHUTDOWN_REBOOT    1   /* Clean shutdown (SHUTDOWN_reboot).     */
 #define CMSG_SHUTDOWN_SUSPEND   2   /* Create suspend info, then             */
                                     /* SHUTDOWN_suspend.                     */
-
+#define CMSG_SHUTDOWN_SYSRQ_MIN 33  /* Lowest subtype that will be interpreted */
+#define CMSG_SHUTDOWN_SYSRQ_MAX 127 /* as an ASCII sysrq handler (and highest) */
 
 /******************************************************************************
  * MEMORY CONTROLS
diff -urN xen-2.0/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c xen-2.0-sysrq/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c
--- xen-2.0/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c	2004-11-17 22:51:41.000000000 +0000
+++ xen-2.0-sysrq/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c	2004-12-03 14:03:58.000000000 +0000
@@ -8,6 +8,7 @@
 #include <linux/unistd.h>
 #include <linux/module.h>
 #include <linux/reboot.h>
+#include <linux/sysrq.h>
 #include <asm/irq.h>
 #include <asm/mmu_context.h>
 #include <asm-xen/ctrl_if.h>
@@ -226,6 +227,15 @@
         shutting_down = msg->subtype;
         schedule_work(&shutdown_work);
     }
+    else if (msg->subtype >= CMSG_SHUTDOWN_SYSRQ_MIN &&
+             msg->subtype <= CMSG_SHUTDOWN_SYSRQ_MAX)
+    {
+#ifdef CONFIG_MAGIC_SYSRQ
+        handle_sysrq(msg->subtype, NULL, NULL);
+#else
+        printk("sysrq not supported\n");
+#endif
+    }
     else
     {
         printk("Ignore spurious shutdown request\n");

Re: Shutdown questions / correct way of sending sysrq to Linux domains?

[Keir Fraser]

It might be neater to add a single CMSG_SHUTDOWN_SYSRQ subtype with an
associated message struct that contains the sysrq level.

 -- Keir

> Hi there,
> 
> I just wanted to check my approach before do a patch that the developers 
> won't like the smell of.  I'm intending to create a method of sending 
> emergency sysrqs from Domain 0 to other domains (patch so far attached).
> 
> This is a useful idea as it allows safe rescues of improperly setup 
> guest systems, and could be a useful backstop for "xm shutdown" after a 
> particular timeout (similar to what we do when we want to shut down a 
> system full of recalcitrant user-mode linux processes that don't do the 
> right thing on a ctrl+alt+delete).
> 
> Does the attached method make sense, i.e. commandeering CMSG_SHUTDOWN 
> subtypes 33-127 to mean "call the sysrq handler"?  If so the only 
> question is how to glue it into the user-space tools: "xm sysrq S" ?  or 
> the counter-intuitive "xm shutdown --sysrq S"?  If the developers can 
> state their preference I'll make a proper job of it.
> 
> cheers,
> 
> -- 
> Matthew Bloch
> diff -urN xen-2.0/xen/include/public/io/domain_controller.h xen-2.0-sysrq/xen/include/public/io/domain_controller.h
> --- xen-2.0/xen/include/public/io/domain_controller.h	2004-11-17 22:51:47.000000000 +0000
> +++ xen-2.0-sysrq/xen/include/public/io/domain_controller.h	2004-12-03 13:39:43.000000000 +0000
> @@ -555,7 +555,8 @@
>  #define CMSG_SHUTDOWN_REBOOT    1   /* Clean shutdown (SHUTDOWN_reboot).     */
>  #define CMSG_SHUTDOWN_SUSPEND   2   /* Create suspend info, then             */
>                                      /* SHUTDOWN_suspend.                     */
> -
> +#define CMSG_SHUTDOWN_SYSRQ_MIN 33  /* Lowest subtype that will be interpreted */
> +#define CMSG_SHUTDOWN_SYSRQ_MAX 127 /* as an ASCII sysrq handler (and highest) */
>  
>  /******************************************************************************
>   * MEMORY CONTROLS
> diff -urN xen-2.0/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c xen-2.0-sysrq/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c
> --- xen-2.0/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c	2004-11-17 22:51:41.000000000 +0000
> +++ xen-2.0-sysrq/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c	2004-12-03 14:03:58.000000000 +0000
> @@ -8,6 +8,7 @@
>  #include <linux/unistd.h>
>  #include <linux/module.h>
>  #include <linux/reboot.h>
> +#include <linux/sysrq.h>
>  #include <asm/irq.h>
>  #include <asm/mmu_context.h>
>  #include <asm-xen/ctrl_if.h>
> @@ -226,6 +227,15 @@
>          shutting_down = msg->subtype;
>          schedule_work(&shutdown_work);
>      }
> +    else if (msg->subtype >= CMSG_SHUTDOWN_SYSRQ_MIN &&
> +             msg->subtype <= CMSG_SHUTDOWN_SYSRQ_MAX)
> +    {
> +#ifdef CONFIG_MAGIC_SYSRQ
> +        handle_sysrq(msg->subtype, NULL, NULL);
> +#else
> +        printk("sysrq not supported\n");
> +#endif
> +    }
>      else
>      {
>          printk("Ignore spurious shutdown request\n");
\x1f -=- MIME -=- \x1f\f

This is a multi-part message in MIME format.
--------------060509050606040705070605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi there,

I just wanted to check my approach before do a patch that the developers 
won't like the smell of.  I'm intending to create a method of sending 
emergency sysrqs from Domain 0 to other domains (patch so far attached).

This is a useful idea as it allows safe rescues of improperly setup 
guest systems, and could be a useful backstop for "xm shutdown" after a 
particular timeout (similar to what we do when we want to shut down a 
system full of recalcitrant user-mode linux processes that don't do the 
right thing on a ctrl+alt+delete).

Does the attached method make sense, i.e. commandeering CMSG_SHUTDOWN 
subtypes 33-127 to mean "call the sysrq handler"?  If so the only 
question is how to glue it into the user-space tools: "xm sysrq S" ?  or 
the counter-intuitive "xm shutdown --sysrq S"?  If the developers can 
state their preference I'll make a proper job of it.

cheers,

-- 
Matthew Bloch

--------------060509050606040705070605
Content-Type: text/plain;
 name="sysrq-patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="sysrq-patch"

diff -urN xen-2.0/xen/include/public/io/domain_controller.h xen-2.0-sysrq/xen/include/public/io/domain_controller.h
--- xen-2.0/xen/include/public/io/domain_controller.h	2004-11-17 22:51:47.000000000 +0000
+++ xen-2.0-sysrq/xen/include/public/io/domain_controller.h	2004-12-03 13:39:43.000000000 +0000
@@ -555,7 +555,8 @@
 #define CMSG_SHUTDOWN_REBOOT    1   /* Clean shutdown (SHUTDOWN_reboot).     */
 #define CMSG_SHUTDOWN_SUSPEND   2   /* Create suspend info, then             */
                                     /* SHUTDOWN_suspend.                     */
-
+#define CMSG_SHUTDOWN_SYSRQ_MIN 33  /* Lowest subtype that will be interpreted */
+#define CMSG_SHUTDOWN_SYSRQ_MAX 127 /* as an ASCII sysrq handler (and highest) */
 
 /******************************************************************************
  * MEMORY CONTROLS
diff -urN xen-2.0/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c xen-2.0-sysrq/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c
--- xen-2.0/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c	2004-11-17 22:51:41.000000000 +0000
+++ xen-2.0-sysrq/linux-2.6.9-xen-sparse/arch/xen/kernel/reboot.c	2004-12-03 14:03:58.000000000 +0000
@@ -8,6 +8,7 @@
 #include <linux/unistd.h>
 #include <linux/module.h>
 #include <linux/reboot.h>
+#include <linux/sysrq.h>
 #include <asm/irq.h>
 #include <asm/mmu_context.h>
 #include <asm-xen/ctrl_if.h>
@@ -226,6 +227,15 @@
         shutting_down = msg->subtype;
         schedule_work(&shutdown_work);
     }
+    else if (msg->subtype >= CMSG_SHUTDOWN_SYSRQ_MIN &&
+             msg->subtype <= CMSG_SHUTDOWN_SYSRQ_MAX)
+    {
+#ifdef CONFIG_MAGIC_SYSRQ
+        handle_sysrq(msg->subtype, NULL, NULL);
+#else
+        printk("sysrq not supported\n");
+#endif
+    }
     else
     {
         printk("Ignore spurious shutdown request\n");

--------------060509050606040705070605--



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Shutdown questions / correct way of sending sysrq to Linux domains?

[Nuno Silva]

Matthew Bloch wrote:

[..]

> subtypes 33-127 to mean "call the sysrq handler"?  If so the only 
> question is how to glue it into the user-space tools: "xm sysrq S" ?  or 
> the counter-intuitive "xm shutdown --sysrq S"?  If the developers can 
> state their preference I'll make a proper job of it.

Besides shutdown functions sysrq may be good for other situations: 
remounting ro, sync the filesystems now, dump task state to console, 
etc. IMHO, having the "xm sysrq X" option would be usefull! :-)

Regards,
Nuno Silva


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/