mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Huang Lei <Lei.Huang@amd.com>
To: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	<xen-devel@lists.xenproject.org>, <linux-doc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <Lei.Huang@amd.com>
Subject: [RFC PATCH] xen/manage: allow forcing shutdown without a userspace helper
Date: Mon, 14 Sep 2026 18:49:45 +0800	[thread overview]
Message-ID: <20260914104945.637-1-Lei.Huang@amd.com> (raw)

From: Lei Huang <Lei.Huang@amd.com>

Xen poweroff, halt and reboot requests are normally forwarded to a
userspace helper so that the guest can perform an orderly shutdown. Some
guests cannot provide a functional helper, for example when their security
policy prevents a kernel-initiated helper from completing the operation.

Add the xen.force_shutdown parameter to let such guests handle toolstack
shutdown requests in workqueue context. Flush filesystems synchronously
before performing the transition directly in the kernel.

This is an explicit bypass rather than a timeout fallback: once a userspace
helper has been executed successfully, the kernel cannot determine whether
it will eventually complete the shutdown.

Keep the parameter disabled by default so existing guests retain the
opportunity to perform userspace cleanup or reject a shutdown request.
Enabling the parameter explicitly accepts the risk of losing userspace data
which has not been committed before the request.

Signed-off-by: Lei Huang <Lei.Huang@amd.com>
---

Notes:
    RFC:
    
    This is an opt-in bypass rather than a timeout fallback. Once a
    userspace helper has been executed successfully, the kernel cannot
    determine whether it will eventually complete the shutdown.
    
    Would a kernel command-line opt-in be acceptable for this case, or
    should the policy be represented through XenStore instead?
    
    Test status:
    
    This exact xen.force_shutdown=1 version was built and booted on a
    Celadon Android Xen PVH guest. An xl shutdown request successfully
    powered off the guest through the direct kernel shutdown path.

 .../admin-guide/kernel-parameters.txt         |  7 +++
 drivers/xen/manage.c                          | 45 +++++++++++++++++--
 2 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b5493a7f8f2..6beda2f3d5b 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -8623,6 +8623,13 @@ Kernel parameters
 			fairer and the number of possible event channels is
 			much higher. Default is on (use fifo events).
 
+	xen.force_shutdown=	[XEN]
+			Force Xen toolstack poweroff, halt and reboot requests in
+			the kernel instead of invoking a userspace helper. This can
+			cause the loss of uncommitted userspace data and should only
+			be enabled for guests without a functional userspace shutdown
+			helper. The default is off.
+
 	xirc2ps_cs=	[NET,PCMCIA]
 			Format:
 			<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index 05d7de128e7..a86426c8671 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -7,14 +7,17 @@
 
 #include <linux/kernel.h>
 #include <linux/err.h>
+#include <linux/moduleparam.h>
 #include <linux/slab.h>
 #include <linux/reboot.h>
+#include <linux/syscalls.h>
 #include <linux/sysrq.h>
 #include <linux/stop_machine.h>
 #include <linux/suspend.h>
 #include <linux/freezer.h>
 #include <linux/syscore_ops.h>
 #include <linux/export.h>
+#include <linux/workqueue.h>
 
 #include <xen/xen.h>
 #include <xen/xenbus.h>
@@ -38,6 +41,14 @@ enum shutdown_state {
 	 SHUTDOWN_HALT = 4,
 };
 
+#undef MODULE_PARAM_PREFIX
+#define MODULE_PARAM_PREFIX "xen."
+
+static bool xen_force_shutdown;
+module_param_named(force_shutdown, xen_force_shutdown, bool, 0444);
+MODULE_PARM_DESC(force_shutdown,
+		 "Force Xen poweroff, halt and reboot requests without a userspace helper");
+
 /* Ignore multiple shutdown requests. */
 static enum shutdown_state shutting_down = SHUTDOWN_INVALID;
 
@@ -189,15 +200,40 @@ static int poweroff_nb(struct notifier_block *cb, unsigned long code, void *unus
 	}
 	return NOTIFY_DONE;
 }
+
+static void xen_poweroff_work_func(struct work_struct *work)
+{
+	pr_warn("Forcing Xen toolstack shutdown without userspace cleanup\n");
+	ksys_sync();
+	kernel_power_off();
+}
+
+static DECLARE_WORK(xen_poweroff_work, xen_poweroff_work_func);
+
+static void xen_reboot_work_func(struct work_struct *work)
+{
+	pr_warn("Forcing Xen toolstack reboot without userspace cleanup\n");
+	ksys_sync();
+	kernel_restart(NULL);
+}
+
+static DECLARE_WORK(xen_reboot_work, xen_reboot_work_func);
+
 static void do_poweroff(void)
 {
 	switch (system_state) {
 	case SYSTEM_BOOTING:
 	case SYSTEM_SCHEDULING:
-		orderly_poweroff(true);
+		if (xen_force_shutdown)
+			schedule_work(&xen_poweroff_work);
+		else
+			orderly_poweroff(true);
 		break;
 	case SYSTEM_RUNNING:
-		orderly_poweroff(false);
+		if (xen_force_shutdown)
+			schedule_work(&xen_poweroff_work);
+		else
+			orderly_poweroff(false);
 		break;
 	default:
 		/* Don't do it when we are halting/rebooting. */
@@ -209,7 +245,10 @@ static void do_poweroff(void)
 static void do_reboot(void)
 {
 	shutting_down = SHUTDOWN_POWEROFF; /* ? */
-	orderly_reboot();
+	if (xen_force_shutdown)
+		schedule_work(&xen_reboot_work);
+	else
+		orderly_reboot();
 }
 
 static const struct shutdown_handler shutdown_handlers[] = {

                 reply	other threads:[~2026-09-14 10:50 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260914104945.637-1-Lei.Huang@amd.com \
    --to=lei.huang@amd.com \
    --cc=corbet@lwn.net \
    --cc=jgross@suse.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=skhan@linuxfoundation.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®