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 507F6C43334 for ; Fri, 10 Jun 2022 14:30:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234152AbiFJOaJ (ORCPT ); Fri, 10 Jun 2022 10:30:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230258AbiFJOaH (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 AFEF913F1D for ; Fri, 10 Jun 2022 07:30:02 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id 187so23988694pfu.9 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=UdBek4qvfQmZhD6PrtMdsuYqBVzRngLBEAogj2qVrQ/hYQF2IoM5H/QAwcSeTwxdeX zlgFptd2vsBRq3kr6eOUWrGpML+LVK510nsS/btCszioFcKxAF2OQoPns8+PVrEJyWQm 8RKSz2JDbtJStJf/Y6Q42/ydOADQsr3oaUltHqH4hWoitMjtptO2LgGXTp2WbkESsKrM FLMepnc10dErXpKbwB3TfL2vyiSmg8nO3u437ZIuQRLzcdw2K3vUPgg/fcjGBXSdccPG Kyzfz5ivLO5VvDwgfWVpSTURFRcS3oy2v1NgOGAOdkX1JLg8q22G+jbLfA7UGmW+MMGC rJ/g== X-Gm-Message-State: AOAM5321pv6mmMj3NGaFaoM++6qxzVXNUjdJMTfpoftzvYBhR3ay83Sd 9D9Gdg8RHOdAPg585QUJSxb+gg== 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: linux-doc@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); }