Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp3539334pxb; Tue, 20 Apr 2021 10:26:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxBZ8YAQ37Gr+gjVsM6LE/sVTWQ6QoZGpooSWeUMk3EqHN0S4TBhdEwY7qkpPmVfUBQvcK5 X-Received: by 2002:a17:907:d04:: with SMTP id gn4mr22104518ejc.152.1618939576010; Tue, 20 Apr 2021 10:26:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618939576; cv=none; d=google.com; s=arc-20160816; b=S8B3Z7aj3ajeS2PpuXx0wpFwnJ3zxOflTfMifzHVWJ4J4cKsF+NRi5v5cPZocoIjTj mZQ9+tn8tcfFBT8yd344zV+7cMU7fl7ZAysZD9mDL/8TKCdmGs3gmihnCWMBfcWuvb2d 6bNaF9KTBNKGWTQPuz81jaZvzzzpwGFoed3SPYDOGGqbePcCxI8/RX1C6dDFJeYzqbgn nGdykvOcpxUqfdmt7vcON4+rNzyIwir/+SXnddKXc4dtpgpwIjRlluZoVEyoXG9NseGX x2mX7vu7WsiIvO+zqlwlDf0GyXAm8L5sbjUH/sTa5IK0SMywf5GIkrjik1d1/nHfRn3e zLMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=PnZ51Qd4+D79y2/gD6y/WyaSioVJc0ih2t9nxA6F6kM=; b=Q27SsL/5oL3dcWWE+PvqhojrUOHeU4cioJnV9c4ag8qHgE70lYMu063mAqqkVMLQz+ 9Mx9yTch9yCrYujzJUXT9/YfVhP3dmcKihCKiEKh0arFYTOhuV5Pq5A2NBLi0x+s5Vyi WjwK14NLTWz/MvDcbo+9sf26W5F3zJvWDE6ZY0IlDy9qbDOZsayCX+2V/KHZDuiJ+ueB rzseuj3vgOIqiKX9oNTsnCBLcCXKqqZ+vhbPfh0T9kOF4ArluIC8AfDRRu1Nst9XPDKt MCdO8EWIZRIJFjNdGk9Mg3hZCeAd7KsCl3k6PhzF7IBHm1R7NMCdgp/BD937Hb8YDEs9 oJIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=VILXmoHb; 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 nd37si13606943ejc.708.2021.04.20.10.25.51; Tue, 20 Apr 2021 10:26:15 -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=VILXmoHb; 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 S233346AbhDTRZP (ORCPT + 99 others); Tue, 20 Apr 2021 13:25:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232913AbhDTRZN (ORCPT ); Tue, 20 Apr 2021 13:25:13 -0400 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72BB2C06138A for ; Tue, 20 Apr 2021 10:24:42 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id j21-20020a17090ae615b02901505b998b45so7418051pjy.0 for ; Tue, 20 Apr 2021 10:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=PnZ51Qd4+D79y2/gD6y/WyaSioVJc0ih2t9nxA6F6kM=; b=VILXmoHbYdOcoS7gaVFYsjv/gO9NOzSTHUygV+Obvzv+cpL/AV3lRwHj633aZsD/rG GTFRNbKKPs1xFwtfTeLLx36VCTW4wA9uR9NYVSbZFxsMYNuAJVdIqt9s85KKRDiOrQI3 DLrkNYr2tpueMObp9opVu0pNlhtQ7LOaDX1FlkeS8nXv8AF3pbc546K2ttI2fud9n4hh rqLZZLN2SvFScsysSPEvOCNlYt9opIOdtXR01PeLUyXJomgW6baXTZqIpnJzh8o2KRAt DohlkYxihUkJCq6q6dVJubjejdGAK26x4+I1vmUD59Wvod7tsNALaPMxYEAlKInATLAV ntuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=PnZ51Qd4+D79y2/gD6y/WyaSioVJc0ih2t9nxA6F6kM=; b=RhrGxSj999VjMZN2yATLLdkAWL2/r/zSSd5lBDA6co9ejCKE0fcF2TM0my2At9ufT/ a64fWFQYZNO/FvU+opshpTbdGlMzHF7wKvUUDz3xMmlFuXcihB5gjQYiJjjcjLt3DD48 hlyzspBuGEzWZ0u8bFtv6JAce1wYqOjtf5+BZXmCkCE4h//CHLrbZ/zvMNoB49bA37yv OtSq253DdpJuUu7W5ZxBYMH6T2rDnHvaRqXtlljwfJOxFiBm2dkDFIfhN+xwJXfngyl0 O6Wdg5W1solS/Ra06lEcYXmFBSeYA27ikOZmZNQrqzCDOrsZlFyTopb6Z9CaoxBnlgH+ 06jA== X-Gm-Message-State: AOAM530TgAEoHrAmrNip+jrOYsZBVyBcSL3sh2/rvm43zBNNeHmXabLP TzNBiXRgIlltaTvDj+NXAQZRFA== X-Received: by 2002:a17:90a:7893:: with SMTP id x19mr6284897pjk.3.1618939481849; Tue, 20 Apr 2021 10:24:41 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id m9sm16483754pgt.65.2021.04.20.10.24.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Apr 2021 10:24:41 -0700 (PDT) Date: Tue, 20 Apr 2021 17:24:37 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Ashish Kalra , tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, joro@8bytes.org, bp@suse.de, thomas.lendacky@amd.com, x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, srutherford@google.com, venu.busireddy@oracle.com, brijesh.singh@amd.com Subject: Re: [PATCH v13 08/12] KVM: X86: Introduce KVM_HC_PAGE_ENC_STATUS hypercall Message-ID: References: <93d7f2c2888315adc48905722574d89699edde33.1618498113.git.ashish.kalra@amd.com> <6e6b4e8c-bbfa-fd58-c1e8-895a157762fe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6e6b4e8c-bbfa-fd58-c1e8-895a157762fe@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 20, 2021, Paolo Bonzini wrote: > On 15/04/21 17:57, Ashish Kalra wrote: > > From: Ashish Kalra > > > > This hypercall is used by the SEV guest to notify a change in the page > > encryption status to the hypervisor. The hypercall should be invoked > > only when the encryption attribute is changed from encrypted -> decrypted > > and vice versa. By default all guest pages are considered encrypted. > > > > The hypercall exits to userspace to manage the guest shared regions and > > integrate with the userspace VMM's migration code. > > I think this should be exposed to userspace as a capability, rather than as > a CPUID bit. Userspace then can enable the capability and set the CPUID bit > if it wants. > > The reason is that userspace could pass KVM_GET_SUPPORTED_CPUID to > KVM_SET_CPUID2 and the hypercall then would break the guest. Right, and that's partly why I was advocating that KVM emulate the MSR as a nop.