From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55D2FCCA47C for ; Fri, 10 Jun 2022 14:30:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235211AbiFJOaK (ORCPT ); Fri, 10 Jun 2022 10:30:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229667AbiFJOaH (ORCPT ); Fri, 10 Jun 2022 10:30:07 -0400 Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB73465C4 for ; Fri, 10 Jun 2022 07:30:02 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id 15so24021769pfy.3 for ; Fri, 10 Jun 2022 07:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=iZkxFrCdz5HGHbN5AvcrMQrT1OxBg7CaPmIJCaX17lQ=; b=KP4HYvtz1/r9i95F1wjVEcLG8E0YRVrsbrMUEtJAGlXCThtn4I+AwBI020BZ8QkENk VkYJUza7vjx9KRxYxYn1blwfJ4DmHGeHYEfXLV2JLucPyU1CcT6RyAiFEGz5xNB1qNs3 /H8oz5Osobi0eyKYL6Jxc/SkFRW8e6Rmy5hPD/ePq+GzeBSEpX/JtBIT336CQfQT3h78 bJKW+VdriFLI+sUb13QBvbPpKxYpaG4Rm0NEHazp3sA5OclNymsh1q+DI3F/mUVofBjx 5cE40h+i7ZQvqjZzKy99OzoR963rVw88+d7oUzCl+YjMBsKs03AJB7Mm5xf283OcfSp5 whAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=iZkxFrCdz5HGHbN5AvcrMQrT1OxBg7CaPmIJCaX17lQ=; b=bh3IRxanxr/M8UUMwxZdE0++WMReWaPC9mu4151uC23JaTRLogNg5mrk4LNbobVUv6 KH+DZBxbk/vigROJJnd1j/3033M5God8BVmIUAyHqnsQouUHJBqvKUHONmCoyhPfvptJ qtbMGHc8A6QFrNrbDwKuR2dSwfEr1Bet45CRmMt7N7qdidebKHToko/kw9hnmuZbL4kj RA6brilOqPvpPqBTNqpOuyeQmnmrvauefw7DiMiOy+YWrVlFPrdnFpkV/N478RkqGeDJ FOQF5BzVHVq+5qYk9KYU7rx3OLEr1iciA2yBbkZ3a5Wucc+OwKU+86L/CO2htfe0ElG9 CufQ== X-Gm-Message-State: AOAM532H/XKeIKsf6EEmIu4L6+//c38sjCATPtSeKgNx1bTeZ84iaSPn mE1gJ2wkMwovfZkiykOcQp1OpA== X-Google-Smtp-Source: ABdhPJy9lH+YdGeVgxW6k3OvjfR+G0rlnFgBcN96oP7+X/9Ctfac88M6IIzXUkvNd0dbwRRp3m0BqA== X-Received: by 2002:a63:8241:0:b0:3fe:2e64:95f0 with SMTP id w62-20020a638241000000b003fe2e6495f0mr13325930pgd.190.1654871401611; Fri, 10 Jun 2022 07:30:01 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id h11-20020a62830b000000b0050dc7628150sm19477473pfe.42.2022.06.10.07.29.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jun 2022 07:29:59 -0700 (PDT) Date: Fri, 10 Jun 2022 14:29:55 +0000 From: Sean Christopherson To: Grzegorz Jaszczyk Cc: linux-kernel@vger.kernel.org, Dmytro Maluka , Zide Chen , Peter Fang , Tomasz Nowicki , Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , "Rafael J. Wysocki" , Len Brown , Pavel Machek , Ashish Kalra , Mario Limonciello , Hans de Goede , Sachi King , Arnaldo Carvalho de Melo , David Dunn , Wei Wang , Nicholas Piggin , "open list:KERNEL VIRTUAL MACHINE (KVM)" , "open list:DOCUMENTATION" , "open list:ACPI" , "open list:HIBERNATION (aka Software Suspend, aka swsusp)" , dbehr@google.com, dtor@google.com Subject: Re: [PATCH 1/2] x86: notify hypervisor about guest entering s2idle state Message-ID: References: <20220609110337.1238762-1-jaz@semihalf.com> <20220609110337.1238762-2-jaz@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Jun 10, 2022, Grzegorz Jaszczyk wrote: > czw., 9 cze 2022 o 16:55 Sean Christopherson napisał(a): > Above could be actually prevented if the VMM had control over the > guest resumption. E.g. after VMM receives notification about guest > entering s2idle state, it would park the vCPU actually preventing it > from exiting s2idle without VMM intervention. Ah, so you avoid races by assuming the VM wakes itself from s2idle any time a vCPU is run, even if the vCPU doesn't actually have a wake event. That would be very useful info to put in the changelog. > > > +static void s2idle_hypervisor_notify(void) > > > +{ > > > + if (static_cpu_has(X86_FEATURE_HYPERVISOR)) > > > + kvm_hypercall0(KVM_HC_SYSTEM_S2IDLE); > > > > Checking the HYPERVISOR flag is not remotely sufficient. The hypervisor may not > > be KVM, and if it is KVM, it may be an older version of KVM that doesn't support > > the hypercall. The latter scenario won't be fatal unless KVM has been modified, > > but blindly doing a hypercall for a different hypervisor could have disastrous > > results, e.g. the registers ABIs are different, so the above will make a random > > request depending on what is in other GPRs. > > Good point: we've actually thought about not confusing/breaking VMMs > so I've introduced KVM_CAP_X86_SYSTEM_S2IDLE VM capability in the > second patch, but not breaking different hypervisors is another story. > Would hiding it under new 's2idle_notify_kvm' module parameter work > for upstream?: No, enumerating support via KVM_CPUID_FEATURES is the correct way to do something like this, e.g. see KVM_FEATURE_CLOCKSOURCE2. But honestly I wouldn't spend too much time understanding how all of that works, because I still feel quite strongly that getting KVM involved is completely unnecessary. A solution that isn't KVM specific is preferable as it can then be implemented by any VMM that enumerates s2idle support to the guest. > > The bigger question is, why is KVM involved at all? KVM is just a dumb pipe out > > to userspace, and not a very good one at that. There are multiple well established > > ways to communicate with the VMM without custom hypercalls. > > Could you please kindly advise about the recommended way of > communication with VMM, taking into account that we want to send this > notification just before entering s2idle state (please see also answer > to next comment), which is at a very late stage of the suspend process > with a lot of functionality already suspended? MMIO or PIO for the actual exit, there's nothing special about hypercalls. As for enumerating to the guest that it should do something, why not add a new ACPI_LPS0_* function? E.g. something like static void s2idle_hypervisor_notify(void) { if (lps0_dsm_func_mask > 0) acpi_sleep_run_lps0_dsm(ACPI_LPS0_EXIT_HYPERVISOR_NOTIFY lps0_dsm_func_mask, lps0_dsm_guid); }