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
|
Home