Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp3967297pxy; Tue, 4 May 2021 14:19:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz8iuX9OzF6bzq0P+SLiMWnPm9u1DS3rKKYXu/ZwfWy9wkWPt1pZ2XOvlqNkByVNeDFzmA+ X-Received: by 2002:a63:40c1:: with SMTP id n184mr24864522pga.219.1620163190917; Tue, 04 May 2021 14:19:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620163190; cv=none; d=google.com; s=arc-20160816; b=ftMcYKtiXKrlp9ygs2xfEpVq2C0XMtDznhffMaxPbMEYCvInUIlYCN+HPuk4HnqnBO aOFODo6HAGoAFKq8/6/nS433IAUNtVco1c2i3B/y4uIuCP4dCSuSHMCnXU212CS9L9fZ oJdLoncgFx373BkZy7s4XJhOSwH3glKJy4/W2IfvYPiwGHJlXZLc7T5QIHz5Ktyhqy01 6Uj9r1abpDoosCGbvs6IdDtKmtgGpSPShrpeqTF9q8g7OZVV9HPNWhap4sRYY1eRRl+K eZp2L6M7g/3el84lSH6izjVZ/3os59gdT9tingf0Sjb6MmZuE8vd8n/05Ztg5rp96RbV d73A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=NO76g2V6YO9liWnh4UbX1vxV8zjs7Pw4ACyPlVCyUgY=; b=xqV5PYB36evSA3DpfioMUMzyXIiz6QvWPtJnUEJH47Tc09Svd2Y1JiRwFokhvY5FyL aMrbKFiO8bWAYjP0Td1nCVCVc+B7Yf+KWrQ2f3ynp95klPLLIDMu7wcHDQSZzrJGA/bg oenKFzmMpNr2CDhcUiTbwHaRPBjIJlU5gLJTiWBboiOwTqSVGK0Aua3+PkBZZv2F26fc ciWvmhGxiOFwnJsm7qfR8xMtOUeiheUs8XixaXb7unXiF/967E8GtB2k9Q3jUPMzDtXN nFejPmWGyGXgDn+haFs2F75Cr5eOwCN2ihWcpNM+3kNkzYl6c7io1oynDBDMnnSgwMSA C1vg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=FxUEulgN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g5si4386490pgm.136.2021.05.04.14.19.34; Tue, 04 May 2021 14:19:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=FxUEulgN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232870AbhEDVRw (ORCPT + 99 others); Tue, 4 May 2021 17:17:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232860AbhEDVRw (ORCPT ); Tue, 4 May 2021 17:17:52 -0400 Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B85E5C061574 for ; Tue, 4 May 2021 14:16:56 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id e2so8566ilr.1 for ; Tue, 04 May 2021 14:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NO76g2V6YO9liWnh4UbX1vxV8zjs7Pw4ACyPlVCyUgY=; b=FxUEulgNjm630aSSiUIdWNw+5aClOyUoVxmAZPKeNQbuP+r6214kJ1TXDXcZGcvzJ6 yVhu1OQilQw9gJ7+VE3diVVksHZN8aV4qoQ3olrWU29HfoXxFQT0QcnPAvZd6EuYOavH XN4Tzf5PmgJugVixxb/fS3RJzh1F7MKD7B9b+hiizf8GGFFN1ChpYONsA+JCtSALwVeK gjEjG7go/wJr46tA+lU7c74kbFQjSAaf2VJONJjm+hi8qib/bkEogLZ9LJUaiJg2CcE3 /miK/WGaphVKGlLNRYqbXqCCBqR5oU2r3cDoTpUP+oinSgd2FRQSy27EZwWAAloDeT2z 9HVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NO76g2V6YO9liWnh4UbX1vxV8zjs7Pw4ACyPlVCyUgY=; b=iO/3KDxp7hky4/yxQ7CNoLh+4eo1AHQnS5CT/yMvIVtwBakcELQz6nwEZKvF7mD2bN /U+Ili/rL74D76vdX8cNe868YF4jQ/fOAIi+2vuE2kz88h8Ar//MSSfZ/JeW7mSOdr3K VwT2RaQXIURZ4lR7UR1/zFvasRDAnjm+ch2rIIbrnSI2bpxxo26PK2D99Dnm2bBN6Ytm uS9FPmF3j4pYwafOjf8QRGfCQzDI4PlGqQFG5852bsbdX5ZY5u4E/e2W/ndUQ2M2QiJ5 V6KKBQ61SRECSI3iVIEf4PipOLAUbM8yb77+/bYTo03wklPrg5KR3ld/dboK7W6aIQIG yHCA== X-Gm-Message-State: AOAM530xHJrZ8zuoMY7+RaYt4AOqNhxTsJzRgawD9Mi2aEXDDMBfRLMf JTuQ1eH1ZQ2NFYEkIEibrUtirHR/s7Z5vREV7Yw+aw== X-Received: by 2002:a05:6e02:1a8d:: with SMTP id k13mr3708510ilv.31.1620163015905; Tue, 04 May 2021 14:16:55 -0700 (PDT) MIME-Version: 1.0 References: <20210429104707.203055-1-pbonzini@redhat.com> <20210429104707.203055-3-pbonzini@redhat.com> <55db8e64-763b-9ecc-9c9a-6d840628e763@redhat.com> In-Reply-To: <55db8e64-763b-9ecc-9c9a-6d840628e763@redhat.com> From: Steve Rutherford Date: Tue, 4 May 2021 14:16:20 -0700 Message-ID: Subject: Re: [PATCH v3 2/2] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall To: Paolo Bonzini Cc: Sean Christopherson , LKML , KVM list , Joerg Roedel , Brijesh Singh , Tom Lendacky , Ashish Kalra , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , X86 ML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 4, 2021 at 1:56 PM Paolo Bonzini wrote: > > On 04/05/21 22:33, Sean Christopherson wrote: > > On Tue, May 04, 2021, Paolo Bonzini wrote: > >> On 04/05/21 19:09, Sean Christopherson wrote: > >>> On Sat, May 01, 2021, Paolo Bonzini wrote: > >>>> - make it completely independent from migration, i.e. it's just a facet of > >>>> MSR_KVM_PAGE_ENC_STATUS saying whether the bitmap is up-to-date. It would > >>>> use CPUID bit as the encryption status bitmap and have no code at all in KVM > >>>> (userspace needs to set up the filter and implement everything). > >>> > >>> If the bit is purely a "page encryption status is up-to-date", what about > >>> overloading KVM_HC_PAGE_ENC_STATUS to handle that status update as well? That > >>> would eliminate my biggest complaint about having what is effectively a single > >>> paravirt feature split into two separate, but intertwined chunks of ABI. > >> > >> It's true that they are intertwined, but I dislike not having a way to read > >> the current state. > > > > From the guest? > > Yes, host userspace obviously doesn't need one since it's implemented > through an MSR filter. It may not be really necessary to read it, but > it's a bit jarring compared to how the rest of the PV APIs uses MSRs. > > Also from a debugging/crashdump point of view the VMM may have an > established way to read an MSR from a vCPU, but it won't work if you > come up with a new way to set the state. Agreed on the preference for an MSR. I particularly appreciate that it reduces the kernel footprint for these changes. Steve