On Fri, Sep 13, 2024 at 12:49:27PM +0530, Naman Jain wrote:
>
>
> 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.
>
Sure, I'll specify this in the next version of the patch.
> 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.
>
Yes, that's correct.
> >Signed-off-by: Saurabh Sengar <ssengar@xxxxxxxxxxxxxxxxxxx>
> >Signed-off-by: Erni Sri Satya Vennela <ernis@xxxxxxxxxxxxxxxxxxx>
> >---
> > 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.
AFAIU, suspend_noirq is used for Suspend-to-Idle operation and we use
"freeze > /sys/power/state" for the same. Maybe the naming convention
comes that way.
The key point to understand here is suspend_noirq prepares the machine
to low power state and freeze_noirq prepares the machine for hibernation
(saving state to disk).
>
> I'll try to understand more on this, but just see if its OK.
>
> > .thaw_noirq = vmbus_resume,
>
> Regards,
> Naman
Yes, thaw_noirq is to restore devices from hibernation state.
