lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v9m9233b.fsf@vitty.brq.redhat.com>
Date:   Wed, 08 Apr 2020 21:24:08 +0200
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Dexuan Cui <decui@...rosoft.com>
Cc:     KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "wei.liu\@kernel.org" <wei.liu@...nel.org>,
        "linux-hyperv\@vger.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        Michael Kelley <mikelley@...rosoft.com>
Subject: RE: [PATCH] Drivers: hv: vmbus: Disallow the freeze PM operation

Dexuan Cui <decui@...rosoft.com> writes:

>> From: Vitaly Kuznetsov <vkuznets@...hat.com>
>> Sent: Wednesday, April 8, 2020 8:47 AM
>> > IMO 'freeze' in a Linux VM on Hyper-V is not really useful in practice,
>> > so let's disallow the operation for both Gen-1 and Gen-2 VMs, even if
>> > it's not an issue for Gen-1 VMs.
>> 
>> Suspend-to-idle may not be very useful indeed, however, it worked before
>> and I think we can just fix it.
>
> How can we fix Suspend-to-idle for a Gen-2 VM, in which no device can work
> as wakeup devices? Note: in the case of Suspend-to-idle, now all the vmbus
> devices including the synthetic keyboard/mouse are suspended completely.
>
> Are you suggesting hv_vmbus should distinguish Suspend-to-idle from
> hibernation, and for the former hv_vmbus should not suspend the synthetic
> keyboard/mouse?

Yes, basically.

>  This should be doable but IMO this is not a very trivial
> effort, and I'm trying to avoid it since IMO Suspend-to-idle is not really 
> useful in practice for a Linux VM on Hyper-V. :-)

Well, to me it's equally (not) useful in all other cases :-) I think we
should Cc: linux-pm@...r.kernel.org and someone will describe a real
world usecase to educate us, we'll then see if there is any Hyper-V
specifics.

>
>> In particular, why do we need to do
>> anything when we are not hibernating?
>
> Are you suggesting hv_vmbus should not suspend the vmbus devices at all
> in the case of Suspend-to-idle?

That what we were doing prior to the hibernation series, right? AFAIU
suspend-to-idle is basically 'no processes are scheduled' mode but we
don't really need to do anything with devices.

>
>> > +/*
>> > + * Note: "freeze/suspend" here means "systemctl suspend".
>> > + * "systemctl hibernate" is still supported.
>> 
>> Let's not use systemd terminology in kernel, let's use the ones from
>> admin-guide/pm/sleep-states.rst (Suspend-to-Idle/Standby/Suspend-to-RAM/
>> Hibernation).
>> --
>> Vitaly
>
> Thanks! I'll use the accurate terms.
>
> Thanks,
> -- Dexuan
>

-- 
Vitaly

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ