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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 133DEC25B79 for ; Thu, 16 May 2024 08:29:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 84AE36B038E; Thu, 16 May 2024 04:29:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FBAC6B038F; Thu, 16 May 2024 04:29:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C3B86B0392; Thu, 16 May 2024 04:29:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4C8CE6B038E for ; Thu, 16 May 2024 04:29:08 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id BD92B120800 for ; Thu, 16 May 2024 08:29:07 +0000 (UTC) X-FDA: 82123583934.04.495DB01 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) by imf25.hostedemail.com (Postfix) with ESMTP id 3EFA9A000C for ; Thu, 16 May 2024 08:29:05 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=bQC0XM80; spf=none (imf25.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 192.198.163.14) smtp.mailfrom=binbin.wu@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715848145; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=z84RRt1HDOXATp/P25/UBY+/f6jXwfXSi3rBGp6xMVQ=; b=ays7lNCRUC0VASlZxfrglDAFgstCydWhu3shac0s5f7l7kB18YqfO4CAWvGdGudQyIJbm9 R6yDrSf+n7Vd80/19rb6wWGPhmoSuaEx3gpsu2I01m+O5V5M24AJGy71TonxY6fzqGS0oO 5LVjc3JlCukrswB+0l3ykZfEb4v4Aw4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=bQC0XM80; spf=none (imf25.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 192.198.163.14) smtp.mailfrom=binbin.wu@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715848145; a=rsa-sha256; cv=none; b=Q8WWuUcE6W/9ujG63HPI5MZvqO80l2qk9vu2QofseHpqelJILACr+QevHBqXKRHPSHy6Ju m4j1/4hKEFMRipsEgsV6kcqYWjXAEWwzWy1rHgT948MvDm1M/U0hhX80ItkdTVDVLAfC50 vzXw0lJB8bYfDY1dLng78hmKlVlyZTA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1715848145; x=1747384145; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=nxv5ycxArjTevmzgBjbrfNCqpXySQ4JMyvIe/0FBJjw=; b=bQC0XM80W/kc1T5w5muxSMexvL9gaLSmqiWcJO1WWJ1NhkIovhx/iDag DW2XnmXaHECWQNe7JB7tWqAr9o9J824Qcfa1d+N6Jk6+rS6h09o+qB8cG wNISCiC1SGxjt3jolpgthzcpd6elOPxjqnwpBpuYg5bgrTZuIPL2hf9D6 G1uIHA7mpeWiAsdfSGR/ws2PmA+7arsDrUojsc59tdOxg+5f5Cil9HXL+ cctUNgmVa93KmRGhJT/SzlWoyRwMmQfsxhjvO+nk46sb+GcRHq6eIzRof f+a3ZAhImImmw0UV31Zh4rquEqmtY4axI6eIz3v9+kOkiVG+E/SHxk0w2 Q==; X-CSE-ConnectionGUID: 9gYQWfieRZe+5NBx+ZjTdQ== X-CSE-MsgGUID: X9q+ArKnSj+vk/bkKzw1ow== X-IronPort-AV: E=McAfee;i="6600,9927,11074"; a="12154486" X-IronPort-AV: E=Sophos;i="6.08,164,1712646000"; d="scan'208";a="12154486" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2024 01:29:03 -0700 X-CSE-ConnectionGUID: a0gWeKCuRbW8XuYagLQEzQ== X-CSE-MsgGUID: IemgONeeRz+3YI5JWUgR+Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,164,1712646000"; d="scan'208";a="31179894" Received: from unknown (HELO [10.238.8.173]) ([10.238.8.173]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2024 01:28:54 -0700 Message-ID: <84e8460d-f8e7-46d7-a274-90ea7aec2203@linux.intel.com> Date: Thu, 16 May 2024 16:28:51 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v15 09/20] KVM: SEV: Add support to handle MSR based Page State Change VMGEXIT To: Michael Roth , kvm@vger.kernel.org Cc: linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, bp@alien8.de, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, jarkko@kernel.org, ashish.kalra@amd.com, nikunj.dadhania@amd.com, pankaj.gupta@amd.com, liam.merwick@oracle.com, Brijesh Singh , "Yamahata, Isaku" References: <20240501085210.2213060-1-michael.roth@amd.com> <20240501085210.2213060-10-michael.roth@amd.com> From: Binbin Wu In-Reply-To: <20240501085210.2213060-10-michael.roth@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3EFA9A000C X-Stat-Signature: f5s8gk43wt9bcr4y1ay3b5853phi1suh X-Rspam-User: X-HE-Tag: 1715848145-571174 X-HE-Meta: U2FsdGVkX1/veHkKIbCfLEhjbHFRQQuzuW8X63Z8BSSxjTqx61SIlRp/cKgWMriGU5K6UCaw4GkbiHQKDQlZmrwwhvayicXd4ERzxAQxgL0iAcp910eg4ybDp7P/ln1dRwGn0HcfhzPYuTVr/j1n6HNbqPiGXFQfK/MeY/3YUyWdmjObfgx0ggE969jmdU7JTYYQCHv4JDbQbiLEoNeLmDKG00SG2c5I0oxnPeeaQMIttaCcn0zNg/1f9nuH2dikOuTE/Kx/jwQ083dg0sPhMTI2iibZKcTYTNEY7SecXlpQ2tf2rNFb1QI6TWXkxizGWpd9gT5gZQZIfzw4w56YlItwbGa5YcOKypg3JwZQaXOU0PArl/aApWL24DuaGqJZ4TXl1ibR3YC4vDZ/GY+Dj7jUva8dWyM3UglmVcxf3iRVo2Ql4by+raCAcs2kK3q1e22jJsEziP2R0FMWrly7mGMHhvH65XmIIA6wGtU8uFGnnR4QnkhH35aQpalHyrd5z7+ITPyzXp7h5beg5e/dpzKWic1w2EBJYBdgekGm2TUBT54hb2kV1IDMhMquTOOkLpYJCERzRQD/CWfFjikJlCY7NSQASQ8laV/3V8Q17qiUe5qMsOWOk1pxT6tr6UvauWPsdttRVw4B1pE94wFwjOFPzpqevVHISBZcBZpWx0ElVclTdS3K2WSWfWO5rXXoK6rEOnuZ65SPC2qnc6VxCgGBMVEJPuMvYBs+ReM3BPZxLJvtw9QCjWJTh5M6XlH9tGhYS/JCjrru7AZcBcr8VP237adg+EN2FECG9Bh2kEztcWOhHZmIgSOMnFi45i9V6zjVJJW+Gp/Eg/RPR0vdvPtGY3eolhvvjLCTtTo4ftkPOjnTGbKvO8U3N/d5AKcx0DlVHDX2StZzRTPVqh2stnwNWplgt1086sceKunyxR8AZt6vz25nYFuiHalRPy9uZdQ/3vjwAywC+c9c0oR sb9/6h2e bDpmM/ApLfLdmFSM5QmV6WYUKzRRes0aRPPC3Yhnbwchi+udUOxz+tUeCTpapUYSHO4oK9didiFiPqHDXgPjbRbSGYBMhJFSklRTvS7SEeudb/+LIIK/Gr1sKZuakxRSvbsw/ULEFPrx6D0Q+lO3JJJzMQYjH5/BFazzzsMLsAGV5sveqtHRHhJwRiW0YupYc0vEGSbQvAyVVYcOinMsMzwYjbysdWHJ94ndZU7TNbkNyvnFARW6FC39X2oaqUPaxePgQ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 5/1/2024 4:51 PM, Michael Roth wrote: > SEV-SNP VMs can ask the hypervisor to change the page state in the RMP > table to be private or shared using the Page State Change MSR protocol > as defined in the GHCB specification. > > When using gmem, private/shared memory is allocated through separate > pools, and KVM relies on userspace issuing a KVM_SET_MEMORY_ATTRIBUTES > KVM ioctl to tell the KVM MMU whether or not a particular GFN should be > backed by private memory or not. > > Forward these page state change requests to userspace so that it can > issue the expected KVM ioctls. The KVM MMU will handle updating the RMP > entries when it is ready to map a private page into a guest. > > Use the existing KVM_HC_MAP_GPA_RANGE hypercall format to deliver these > requests to userspace via KVM_EXIT_HYPERCALL. > > Signed-off-by: Michael Roth > Co-developed-by: Brijesh Singh > Signed-off-by: Brijesh Singh > Signed-off-by: Ashish Kalra > --- > arch/x86/include/asm/sev-common.h | 6 ++++ > arch/x86/kvm/svm/sev.c | 48 +++++++++++++++++++++++++++++++ > 2 files changed, 54 insertions(+) > > diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h > index 1006bfffe07a..6d68db812de1 100644 > --- a/arch/x86/include/asm/sev-common.h > +++ b/arch/x86/include/asm/sev-common.h > @@ -101,11 +101,17 @@ enum psc_op { > /* GHCBData[11:0] */ \ > GHCB_MSR_PSC_REQ) > > +#define GHCB_MSR_PSC_REQ_TO_GFN(msr) (((msr) & GENMASK_ULL(51, 12)) >> 12) > +#define GHCB_MSR_PSC_REQ_TO_OP(msr) (((msr) & GENMASK_ULL(55, 52)) >> 52) > + > #define GHCB_MSR_PSC_RESP 0x015 > #define GHCB_MSR_PSC_RESP_VAL(val) \ > /* GHCBData[63:32] */ \ > (((u64)(val) & GENMASK_ULL(63, 32)) >> 32) > > +/* Set highest bit as a generic error response */ > +#define GHCB_MSR_PSC_RESP_ERROR (BIT_ULL(63) | GHCB_MSR_PSC_RESP) > + > /* GHCB Hypervisor Feature Request/Response */ > #define GHCB_MSR_HV_FT_REQ 0x080 > #define GHCB_MSR_HV_FT_RESP 0x081 > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index e1ac5af4cb74..720775c9d0b8 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -3461,6 +3461,48 @@ static void set_ghcb_msr(struct vcpu_svm *svm, u64 value) > svm->vmcb->control.ghcb_gpa = value; > } > > +static int snp_complete_psc_msr(struct kvm_vcpu *vcpu) > +{ > + struct vcpu_svm *svm = to_svm(vcpu); > + > + if (vcpu->run->hypercall.ret) Do we have definition of ret? I didn't find clear documentation about it. According to the code, 0 means succssful. Is there any other error codes need to or can be interpreted? For TDX, it may also want to use KVM_HC_MAP_GPA_RANGE hypercall  to userspace via KVM_EXIT_HYPERCALL. > + set_ghcb_msr(svm, GHCB_MSR_PSC_RESP_ERROR); > + else > + set_ghcb_msr(svm, GHCB_MSR_PSC_RESP); > + > + return 1; /* resume guest */ > +} > [...]