[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b480a355-dbfa-4422-ad3c-65ec931a3ba0@linux.microsoft.com>
Date: Fri, 13 Sep 2024 12:49:27 +0530
From: Naman Jain <namjain@...ux.microsoft.com>
To: Erni Sri Satya Vennela <ernis@...ux.microsoft.com>, kys@...rosoft.com,
haiyangz@...rosoft.com, wei.liu@...nel.org, decui@...rosoft.com,
jikos@...nel.org, bentiss@...nel.org, dmitry.torokhov@...il.com,
linux-hyperv@...r.kernel.org, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: ernis@...rosoft.com, Saurabh Sengar <ssengar@...ux.microsoft.com>
Subject: Re: [PATCH 1/3] Drivers: hv: vmbus: Disable Suspend-to-Idle for VMBus
On 9/13/2024 2:57 AM, Erni Sri Satya Vennela wrote:
> If the Virtual Machine Connection window is focused,
> a Hyper-V VM user can unintentionally touch the keyboard/mouse
> when the VM is hibernating or resuming, and consequently the
> hibernation or resume operation can be aborted unexpectedly.
> Fix the issue by no longer registering the keyboard/mouse as
> wakeup devices (see the other two patches for the
> changes to drivers/input/serio/hyperv-keyboard.c and
> drivers/hid/hid-hyperv.c).
>
> The keyboard/mouse were registered as wakeup devices because the
> VM needs to be woken up from the Suspend-to-Idle state after
> a user runs "echo freeze > /sys/power/state". It seems like
> the Suspend-to-Idle feature has no real users in practice, so
> let's no longer support that by returning -EOPNOTSUPP if a
> user tries to use that.
>
Maybe it would be good to capture here the kind of VMs that this is
going to be not supported - HyperV based VMs. You mentioned it in cover
letter, but it would be good to add it here as well, as cover letter
does not go to git log.
Also, the subject suggests that we are disabling suspend-to-idle for
vmbus specifically, but from commit description, it suggests that
"suspend to idle" feature itself is no longer supported on these
particular VMs. Please rephrase it based on what exactly we are trying
to do here. IIUC, we are now returning an error (EOPNOTSUPP) in vmbus
driver callback, which insures that we don't support Suspend-to-Idle in
these VMs.
> Signed-off-by: Saurabh Sengar <ssengar@...ux.microsoft.com>
> Signed-off-by: Erni Sri Satya Vennela <ernis@...ux.microsoft.com>
> ---
> drivers/hv/vmbus_drv.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 965d2a4efb7e..4efd8856392f 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -900,6 +900,19 @@ static void vmbus_shutdown(struct device *child_device)
> }
>
> #ifdef CONFIG_PM_SLEEP
> +/*
> + * vmbus_freeze - Suspend-to-Idle
> + */
> +static int vmbus_freeze(struct device *child_device)
> +{
> +/*
> + * Do not support Suspend-to-Idle ("echo freeze > /sys/power/state") as
> + * that would require registering the Hyper-V synthetic mouse/keyboard
> + * devices as wakeup devices, which can abort hibernation/resume unexpectedly.
> + */
> + return -EOPNOTSUPP;
> +}
> +
> /*
> * vmbus_suspend - Suspend a vmbus device
> */
> @@ -969,7 +982,7 @@ static void vmbus_device_release(struct device *device)
> */
>
> static const struct dev_pm_ops vmbus_pm = {
> - .suspend_noirq = NULL,
> + .suspend_noirq = vmbus_freeze,
> .resume_noirq = NULL,
> .freeze_noirq = vmbus_suspend,
I am not sure if this is OK or how it works, but this naming scheme
seems a bit confusing to me -
*suspend* -> vmbus_*freeze*
*freeze* -> vmbus_*suspend*
and we are removing support for "freeze" by returning EOPNOTSUPP in
suspend callback.
I'll try to understand more on this, but just see if its OK.
> .thaw_noirq = vmbus_resume,
Regards,
Naman
Powered by blists - more mailing lists