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 X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE248C2BBD4 for ; Thu, 10 Dec 2020 23:06:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9897423B85 for ; Thu, 10 Dec 2020 23:06:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405106AbgLJWbp (ORCPT ); Thu, 10 Dec 2020 17:31:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:60072 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405114AbgLJWY2 (ORCPT ); Thu, 10 Dec 2020 17:24:28 -0500 X-Gm-Message-State: AOAM533iQCX9Rm5VbO/hL6hPW3yWJDbnMAqe0cJ12mcTbVhXCefhWQrj pMNMy7c22dwMsZx/FFN2jRZrAENrMyOL8WBnDGXxuw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1607637685; bh=4yt8h1Q+CPGGcT2IO75cM/fN5M+tD+08bKTLE18FGBc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=mMWvnIShKAgYdcX4PZb8dm3EICOtgYX6trNmFvewYP950g4nA7qZFUO3aspNqYyCV W0nMO4Uiv0A2JNQScze/bR1D4r6sLp1z2j28hPPzB6E7JWlAXMkYdytq1ETss+zhBA qpTcen55RpIcHCr5sRoWE1BCFgn6MvS1STdBvxgXl0DL5mOvmPpl3if8LgQIVj1rSI lNTnmlAZYUI1R+GPk87at/QKlEDpe1actw0jFqS+cNmc5/RaP75d2h4fJpEFk31ILP PlPRX0c1sUGmfWEbf2cNXeaSFee43sbhR7LQ+0dZdPlBxZqETopmAVlZJ5JbGveVVK bG92QEYqTL55A== X-Google-Smtp-Source: ABdhPJzF2a9E+mCWo9M4tLmMpSz+6JMPjrTXsFPQMg/z71zkpXbGLbBH1iCVRxG8tDVwZozqBfsoJUXetLw8AUPWzi8= X-Received: by 2002:adf:e98c:: with SMTP id h12mr10402629wrm.75.1607637683968; Thu, 10 Dec 2020 14:01:23 -0800 (PST) MIME-Version: 1.0 References: <9389c1198da174bcc9483d6ebf535405aa8bdb45.camel@redhat.com> <87360djqve.fsf@nanos.tec.linutronix.de> In-Reply-To: <87360djqve.fsf@nanos.tec.linutronix.de> From: Andy Lutomirski Date: Thu, 10 Dec 2020 14:01:12 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/3] KVM: x86: implement KVM_{GET|SET}_TSC_STATE To: Thomas Gleixner Cc: Maxim Levitsky , Paolo Bonzini , Marcelo Tosatti , kvm list , "H. Peter Anvin" , Jonathan Corbet , Jim Mattson , Wanpeng Li , "open list:KERNEL SELFTEST FRAMEWORK" , Vitaly Kuznetsov , Sean Christopherson , open list , Ingo Molnar , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Joerg Roedel , Borislav Petkov , Shuah Khan , Andrew Jones , Oliver Upton , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 10, 2020 at 1:25 PM Thomas Gleixner wrote: > > Andy, > > > I'm still convinced that a notification about 'we take a nap' will be > more robust, less complex and more trivial to backport. What do you have in mind? Suppose the host kernel sends the guest an interrupt on all vCPUs saying "I'm about to take a nap". What happens if the guest is busy with IRQs off for a little bit? Does the host guarantee the guest a certain about of time to try to get the interrupt delivered before allowing the host to enter S3? How about if the host wants to reboot for a security fix -- how long is a guest allowed to delay the process? I'm sure this can all be made to work 99% of time, but I'm a bit concerned about that last 1%. --Andy