linux-kernel - Re: [PATCH 1/2] x86: notify hypervisor about guest entering s2idle state

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YrSZIxfWUJoQqEt/@google.com>
Date:   Thu, 23 Jun 2022 16:47:31 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     "Limonciello, Mario" <mario.limonciello@....com>
Cc:     Grzegorz Jaszczyk <jaz@...ihalf.com>, linux-kernel@...r.kernel.org,
        Dmytro Maluka <dmy@...ihalf.com>,
        Zide Chen <zide.chen@...el.corp-partner.google.com>,
        Peter Fang <peter.fang@...el.corp-partner.google.com>,
        Tomasz Nowicki <tn@...ihalf.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>, Pavel Machek <pavel@....cz>,
        Ashish Kalra <ashish.kalra@....com>,
        Hans de Goede <hdegoede@...hat.com>,
        Sachi King <nakato@...ato.io>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        David Dunn <daviddunn@...gle.com>,
        Wei Wang <wei.w.wang@...el.com>,
        Nicholas Piggin <npiggin@...il.com>,
        "open list:KERNEL VIRTUAL MACHINE (KVM)" <kvm@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        "open list:ACPI" <linux-acpi@...r.kernel.org>,
        "open list:HIBERNATION (aka Software Suspend, aka swsusp)" 
        <linux-pm@...r.kernel.org>, Dominik Behr <dbehr@...gle.com>,
        Dmitry Torokhov <dtor@...gle.com>
Subject: Re: [PATCH 1/2] x86: notify hypervisor about guest entering s2idle
 state

On Wed, Jun 22, 2022, Limonciello, Mario wrote:
> On 6/22/2022 04:53, Grzegorz Jaszczyk wrote:
> > It will be problematic since the abort/restore notification could
> > arrive too late and therefore the whole system will go to suspend
> > thinking that the guest is in desired s2ilde state. Also in this case
> > it would be impossible to prevent races and actually making sure that
> > the guest is suspended or not. We already had similar discussion with
> > Sean earlier in this thread why the notification have to be send just
> > before swait_event_exclusive(s2idle_wait_head, s2idle_state ==
> > S2IDLE_STATE_WAKE) and that the VMM have to have control over guest
> > resumption.
> > 
> > Nevertheless if extending acpi_s2idle_dev_ops is possible, why not
> > extend it about the hypervisor_notify() and use it in the same place
> > where the hypercall is used in this patch? Do you see any issue with
> > that?
> 
> If this needs to be a hypercall and the hypercall needs to go at that
> specific time, I wouldn't bother with extending acpi_s2idle_dev_ops. The
> whole idea there was that this would be less custom and could follow a spec.

It doesn't need to be a hypercall though.  PIO and MMIO provide the same "exit to
host userspace" behavior, and there is zero reason to get KVM involved since KVM
(on x86) doesn't deal with platform scoped power management.

I get that squeezing this into the ACPI device model is awkward, but forcing KVM
into the picture isn't any better.

> TBH - given the strong dependency on being the very last command and this
> being all Linux specific (you won't need to do something similar with
> Windows) - I think the way you already did it makes the most sense.
> It seems to me the ACPI device model doesn't really work well for this
> scenario.