Xen project Mailing List

Re: [Xen-devel] Shutdown questions / correct way of sending sysrq to Linux domains?

To: Matthew Bloch <matthew@xxxxxxxxxxxxxx>

From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>

Date: Sat, 04 Dec 2004 20:51:04 +0000

Delivery-date: Sat, 04 Dec 2004 20:52:26 +0000

List-id: List for Xen developers <xen-devel.lists.sourceforge.net>

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

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.