[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM5PR2101MB104763C3447F4BB9C163F8F0D70C0@DM5PR2101MB1047.namprd21.prod.outlook.com>
Date: Wed, 22 Jan 2020 17:16:20 +0000
From: Michael Kelley <mikelley@...rosoft.com>
To: Dexuan Cui <decui@...rosoft.com>,
KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
"sashal@...nel.org" <sashal@...nel.org>,
Sasha Levin <Alexander.Levin@...rosoft.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
vkuznets <vkuznets@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 2/4] hv_utils: Support host-initiated restart request
From: Dexuan Cui <decui@...rosoft.com> Sent: Sunday, January 12, 2020 10:31 PM
>
>
> To test the code, run this command on the host:
>
> Restart-VM $vm -Type Reboot
>
Need a better commit message here. How about:
The hv_util driver currently supports a "shutdown" operation initiated from the
Hyper-V host. Newer versions of Hyper-V also support a "restart" operation. So
add support for the updated protocol version that has "restart" support, and
perform a clean reboot when such a message is received from Hyper-V.
To test the restart functionality, run this PowerShell command on the Hyper-V host:
Restart-VM <vmname> -Type Reboot
>
> Signed-off-by: Dexuan Cui <decui@...rosoft.com>
> ---
> drivers/hv/hv_util.c | 23 ++++++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
> index 766bd8457346..fe3a316380c2 100644
> --- a/drivers/hv/hv_util.c
> +++ b/drivers/hv/hv_util.c
> @@ -24,6 +24,8 @@
>
> #define SD_MAJOR 3
> #define SD_MINOR 0
> +#define SD_MINOR_1 1
> +#define SD_VERSION_3_1 (SD_MAJOR << 16 | SD_MINOR_1)
> #define SD_VERSION (SD_MAJOR << 16 | SD_MINOR)
>
> #define SD_MAJOR_1 1
> @@ -50,8 +52,9 @@ static int sd_srv_version;
> static int ts_srv_version;
> static int hb_srv_version;
>
> -#define SD_VER_COUNT 2
> +#define SD_VER_COUNT 3
> static const int sd_versions[] = {
> + SD_VERSION_3_1,
> SD_VERSION,
> SD_VERSION_1
> };
> @@ -118,11 +121,21 @@ static void perform_shutdown(struct work_struct *dummy)
> orderly_poweroff(true);
> }
>
> +static void perform_restart(struct work_struct *dummy)
> +{
> + orderly_reboot();
> +}
> +
> /*
> * Perform the shutdown operation in a thread context.
> */
> static DECLARE_WORK(shutdown_work, perform_shutdown);
>
> +/*
> + * Perform the restart operation in a thread context.
> + */
> +static DECLARE_WORK(restart_work, perform_restart);
> +
> static void shutdown_onchannelcallback(void *context)
> {
> struct vmbus_channel *channel = context;
> @@ -166,6 +179,14 @@ static void shutdown_onchannelcallback(void *context)
> pr_info("Shutdown request received -"
> " graceful shutdown initiated\n");
> break;
> + case 2:
> + case 3:
How are the flags values 0, 1, 2, and 3 interpreted? Perhaps a short comment
would be helpful.
> + pr_info("Restart request received -"
> + " graceful restart initiated\n");
> + icmsghdrp->status = HV_S_OK;
> +
> + schedule_work(&restart_work);
> + break;
For case 0 and 1 (shutdown), the schedule_work() call is performed only
after the response packet has been sent to the host. Is there a reason the
new code for case 2 and 3 (restart) is doing it in the opposite order?
> default:
> icmsghdrp->status = HV_E_FAIL;
> execute_shutdown = false;
> --
> 2.19.1
Powered by blists - more mailing lists