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 1D368C25B77 for ; Tue, 21 May 2024 00:50:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A19AD6B0089; Mon, 20 May 2024 20:50:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A2A86B008A; Mon, 20 May 2024 20:50:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 869D66B008C; Mon, 20 May 2024 20:50:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6661F6B0089 for ; Mon, 20 May 2024 20:50:15 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 02CCE40F6B for ; Tue, 21 May 2024 00:50:14 +0000 (UTC) X-FDA: 82140571590.23.05D1E22 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by imf10.hostedemail.com (Postfix) with ESMTP id 5CA42C0004 for ; Tue, 21 May 2024 00:50:12 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LDiHNIyJ; spf=none (imf10.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 198.175.65.16) 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=1716252612; 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=GKFVzTNcPWGmxwVhVa1G2St50KjU0YU+PtkGc2RRswc=; b=Vv2mN8E9WUKq4gUX7jQP/AFd0F3OIBwDT5RDPyfuZSZgwHWWNER6m+/AB6uGYeWpEomYa9 QCSUR3+NEwXSWzVLjm/AFQsE/jKECBdAx2I90olkkKIrO68iKTAaJXQN3jQ3+XyZrG8o23 xa0n9GqQX2vAp1CRLIFGNYQl65BmbNg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LDiHNIyJ; spf=none (imf10.hostedemail.com: domain of binbin.wu@linux.intel.com has no SPF policy when checking 198.175.65.16) 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=1716252612; a=rsa-sha256; cv=none; b=5FP/HQiFb5Nzh+BOU4Pmm6y1rxqAKRbOy/JOv2kA4cllC3tu8OyooMgdLpUTPEgptAiGEZ MALD7l89+ytg1KnKZXGhsxxcVZuuW1zkPsumoFWHVlGms10WO1/n0Zw6QVsCG+xf4UfsPA WzmTas2wqImjnd80gBBtc/i3yVjCPQ4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1716252613; x=1747788613; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=bmp8fr++SX2ZpALlJv3IjLJSzc2ON4Zni7XoFdvDuDY=; b=LDiHNIyJ3j5tDMZJKpxLjKtOvoBK7PIfDhJoDaozFlAk3b+bGFexY5UG bOVe3wGLA/jxoLOP+OyqX2GeWX1OkxmWe/bMkiFD6vBXQitHNF1e+khVi hv/wXfabjpRXpApvReaHmCfy0WEZ9HNoMreQu5bhaSh9THrot9PWQXoHy VOIwXnlqXWk2n966KMG9tFD3Vt+fly0fBFCDswwweiAQ4nWJqmBUMMgQx KLgJW1dcBfhtmyGBOlveBD7oAv7sL2Tqzm7MtVAt600D63XhdR2XKF3Fe 4ODJXaR2zm7hVlTGL+zlJkSETSQpnCQfp5nGjOWK873gdhDhiitqj7r4E Q==; X-CSE-ConnectionGUID: 9MS+yv+6RZe6d5eWRGz5eA== X-CSE-MsgGUID: lR0L9x8nRty6QAzXkt/g+g== X-IronPort-AV: E=McAfee;i="6600,9927,11078"; a="12528652" X-IronPort-AV: E=Sophos;i="6.08,176,1712646000"; d="scan'208";a="12528652" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2024 17:50:11 -0700 X-CSE-ConnectionGUID: qEl6I9APROCpPWpfMZ49fw== X-CSE-MsgGUID: k0zPN6EnRx2Q9MmHNETa3w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,176,1712646000"; d="scan'208";a="32618014" Received: from unknown (HELO [10.238.8.173]) ([10.238.8.173]) by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2024 17:50:02 -0700 Message-ID: <7d6a4320-89f5-48ce-95ff-54b00e7e9597@linux.intel.com> Date: Tue, 21 May 2024 08:49:59 +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: Paolo Bonzini Cc: Michael Roth , kvm@vger.kernel.org, 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, 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> <84e8460d-f8e7-46d7-a274-90ea7aec2203@linux.intel.com> Content-Language: en-US From: Binbin Wu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 5CA42C0004 X-Stat-Signature: xsez4hnpkcbg5dr431e6tf66cqyymgtn X-Rspam-User: X-HE-Tag: 1716252612-955966 X-HE-Meta: U2FsdGVkX1+Bzb2SGK6Bkdg6EwhWW9/lmH5Qe3CuT8KuZ4gqC/skOORM5/vWoJyIGNR8E3MMYD7XgS6PGIlQSnPp5Nrg6DrLHWaoS2UyntY5r5Hbo9CuWpaK8wl0MFda8j7zawySDVl6ZGpeJk+VbG5wpt7+9mIC9fP/6f7qpFeGftVTTAMSelEPyTuFs1J5rr7ngxnYCnYUe7DooKEmSJuuWVHn26WjgDcz3/Q7vU1lqpjy9vzOBfYnFMVB99yLTC9X4LA/RSR54dKY4pTGpWJAB+tUZ72r67IH4iA+iZweuQnS+MVKLR6S49FMcu+IPAPWraryMKSWUAnLKvCMSkd0+C7Anmj3HU/Q3aqg+f/hJnEDLszOAZN1kY3iACpyF4T7bb4A5/qoQt+IidIuIqtAYDaftYtAOjM/QRCKBmVGTnbFwYMGl99kqTHT4xp/mhgjP/rPp6UEMPtQwOvtbqSn8OiqwCX0c/PwnL2pJfHdyrWL8R6r04U431++YQUpxAX97I8UbhQl//1xexVjCzZB2jT1uaPJgHx0Wy0VUcQ9LdAXNX5JENwvoZQpix1lHmcyc/V/8cUAEpTS/rlTvsBMyKpN01Z/3wBhmw/RCVuMbZtCX/47u6tswE8hMI74aqfKsZ2167m6t4PpAxOwq9HJ9ycFZjdJSz9XqRr/b695izR9IAyh9cr4CREB4anSjykpDR4M7r7zy7jJOw49ESsM08+mHh6oMgfnX4hKCQnZC46fheuzlLlsls44aNN6DKrKcwH7NwCPpS9Y/XtYUcPTbi+oLkT/H7tdGf20a6Z8QhH47Eb2lZF5RE3nM5iSJ3KE9bPiCDTKDnBbM3z7EtXXg1fl2xs/XxfJ5ZgeJvXFogCCRCrj5v+zPODE+bFXmcs/fJQoqZLPZLSisbqIN8zQYuiXzMwKuMbNOGfCxv/OqJYHyAAO+SItuBSMrTSnj5PPAC4mFnlvXFC1O8b ecLjxYQA OIMrfwtRsLMZF42L5YKhvhZmKdntR2NjALrswxVp2L/GLSjTKrm4Q0eb3iQZQhqA0spq5Er6U+vkkK/sK9GJvbraaZ+4IbfafzFnp7cmuKf7H0ck+WKXq5FBnVijxelU49FJ0K506O6Q07pZKieVgY5vSftYiWZFUeakFMM+l67tuEPMcJ6cGlnmYKMfUiERRX7F89DkvQ6VkokWrLjUteaoqxh8YdVDEHbHdf5FUucnGOIRwCY07rEiuaVBiWQP7g6j9vQWl6vSqnATGD5qsmhHnX/ep08yngGcQc66Q8SVrzaE= 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/17/2024 1:23 AM, Paolo Bonzini wrote: > On Thu, May 16, 2024 at 10:29 AM Binbin Wu wrote: >> >> >> 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? > They are defined in include/uapi/linux/kvm_para.h > > #define KVM_ENOSYS 1000 > #define KVM_EFAULT EFAULT /* 14 */ > #define KVM_EINVAL EINVAL /* 22 */ > #define KVM_E2BIG E2BIG /* 7 */ > #define KVM_EPERM EPERM /* 1*/ > #define KVM_EOPNOTSUPP 95 > > Linux however does not expect the hypercall to fail for SEV/SEV-ES; and > it will terminate the guest if the PSC operation fails for SEV-SNP. So > it's best for userspace if the hypercall always succeeds. :) Thanks for the info. For TDX, it wants to restrict the size of memory range for conversion in one hypercall to avoid a too long latency. Previously, in TDX QEMU patchset v5, the limitation is in userspace and  if the size is too big, the status_code will set to TDG_VP_VMCALL_RETRY and the failed GPA for guest to retry is updated. https://lore.kernel.org/all/20240229063726.610065-51-xiaoyao.li@intel.com/ When TDX converts TDVMCALL_MAP_GPA to KVM_HC_MAP_GPA_RANGE, do you think which is more reasonable to set the restriction? In KVM (TDX specific code) or userspace? If userspace is preferred, then the interface needs to  be extended to support it. > >> For TDX, it may also want to use KVM_HC_MAP_GPA_RANGE hypercall to >> userspace via KVM_EXIT_HYPERCALL. > Yes, definitely. > > Paolo >