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] Shutdown questions / correct way of sending sysrq to Lin

To: Matthew Bloch <matthew@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Shutdown questions / correct way of sending sysrq to Linux domains?
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 04 Dec 2004 20:51:04 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 04 Dec 2004 20:52:26 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: Your message of "Fri, 03 Dec 2004 14:30:55 GMT." <coptc5$ejb$1@xxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
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");
 -=- MIME -=- 
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@xxxxxxxxxxxxxxxxxxxxx
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/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

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