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 1C6DFC32793 for ; Wed, 18 Jan 2023 18:15:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 904E56B0072; Wed, 18 Jan 2023 13:15:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B5B56B0075; Wed, 18 Jan 2023 13:15:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 756586B007B; Wed, 18 Jan 2023 13:15:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 655C46B0072 for ; Wed, 18 Jan 2023 13:15:53 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3F709C0516 for ; Wed, 18 Jan 2023 18:15:53 +0000 (UTC) X-FDA: 80368723386.15.B4C91F0 Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) by imf28.hostedemail.com (Postfix) with ESMTP id 8D973C0019 for ; Wed, 18 Jan 2023 18:15:50 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=FXN2VCbM; spf=pass (imf28.hostedemail.com: domain of alpergun@google.com designates 209.85.166.175 as permitted sender) smtp.mailfrom=alpergun@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674065750; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qFMvi2a6L2BPNbil1Z3ukPsrERB30WY5FsfmzneS0xY=; b=HSxcZTLtqYUYeWSEbxXW2q0/Zukitw8O920zldSBOZsZA5gd+ZQU/Aaj3LNnP+fUnFbYOt nYI/XmAn6eolUnc7wHHbk0SPi4vgrKSBEtJ00sxjQikI1WaO67EthBrZX2lidhfWZ/RQ2m i0tcOBRgfZCQsJpJdgXfJlFQG+X2FyU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=FXN2VCbM; spf=pass (imf28.hostedemail.com: domain of alpergun@google.com designates 209.85.166.175 as permitted sender) smtp.mailfrom=alpergun@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674065750; a=rsa-sha256; cv=none; b=CkMi+RvDN1ts1xqYCyIafImZk+1m4w/hPLEIVjSiFQtpUpoh6bL3x5qo3DHfMcgxrp3HyM Cvvq5I1lzOZbLYr06BsJSmMueYkWM8vqdfkJooDI1OpozrYbbA8qubqXSPeeHCoffpU8Qj OllMEhPQaAB8BEvjD6yVQV2WP76tIEY= Received: by mail-il1-f175.google.com with SMTP id g2so17446237ila.4 for ; Wed, 18 Jan 2023 10:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qFMvi2a6L2BPNbil1Z3ukPsrERB30WY5FsfmzneS0xY=; b=FXN2VCbM00KvzRkLSjJCig2q0kiMeLGNdPtqDsL6Sn+DpZ+Rfxrxmut8jlbmR5reSW MrN/046C1mOXE04WG8BP9Ag0tGSdsv3J1z3DLT+Ft+cTDKo0Fc8nHcQtX93SChBeTB3S v+M0dtOnqM6E0LcYWrXGlAWURLkqAyXlfgRZUmty3DrKEjdVUMAJTpxYB9sMafWHFfnQ Hw1IkSK/+hFION0jdBrcEI5Z2Pi0CTrplRkhpS3r4GLCFizUFFazRU1xi37XSU1WjSSS GhASTTqJtcHutSoQlKJhlVJhKCKta6qfDEEx/dft6aFS/IzYIBXXmaQXjCEYcOjx29Of zquQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qFMvi2a6L2BPNbil1Z3ukPsrERB30WY5FsfmzneS0xY=; b=p9RjrQRaIQAh1uOSI2NMVpaSaJxI5swuBJK4OW2DRwp8IjkJ1NPxFp9xmZZ/VrM+0L +D5I8Dh9twKlihCftEotgpoy3rrulwqWh3b8KyDPZIKwMCkl3tXXkhUV8eEn4uBTKNS5 NPVjNfOx+608pVfdABviUz8cENlfKwkgiSwEK3uwkjW38YrWZX+/WhYhMFuaUdcK0vHB OfnYGVlvxsPgHrG2QjoTcWlhsvwJW4hhaqjeu4i9/0zkrKulyks/N6MvtlkP+zROQCm0 IuXF8rksfXKUPQLNL5VsqMF/KGfwosauYjNG7GPFkZQKFxEgAu8WzYj+bE/j6aL5SkWk +ZMQ== X-Gm-Message-State: AFqh2krFbAy6FZcFcrbT13WsMMy9UYFTvwUDjM620Ek62ol4ozaL5vgQ g9ZKOwdHRsxDaYrqGXvSGd8eMcCvv3B7/N/PJcDjeQ== X-Google-Smtp-Source: AMrXdXv6zW3mUb3uJJYwWd8l/Zc0mUhiArEpYUTm10kiV+NXSFLzq7Rpx0/aHPDhA/yUTebrZSMnVWp7fevFEhGvFro= X-Received: by 2002:a92:d911:0:b0:30d:a0c6:55a3 with SMTP id s17-20020a92d911000000b0030da0c655a3mr951212iln.199.1674065749311; Wed, 18 Jan 2023 10:15:49 -0800 (PST) MIME-Version: 1.0 References: <20221214194056.161492-1-michael.roth@amd.com> <20221214194056.161492-45-michael.roth@amd.com> <20230118152721.GA24742@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> In-Reply-To: <20230118152721.GA24742@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: Alper Gun Date: Wed, 18 Jan 2023 10:15:38 -0800 Message-ID: Subject: Re: [PATCH RFC v7 44/64] KVM: SVM: Remove the long-lived GHCB host map To: Jeremi Piotrowski 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, pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, wanpengli@tencent.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, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, dgilbert@redhat.com, jarkko@kernel.org, ashish.kalra@amd.com, harald@profian.com, Brijesh Singh Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8D973C0019 X-Rspam-User: X-Stat-Signature: wetqmejmocwp1yqwpqrtwajf4tsq973x X-HE-Tag: 1674065750-379948 X-HE-Meta: U2FsdGVkX19UdbTTipFyD4p9o4DF3bL25DRiFUaGNAm52NXMHSdYxCEFQhI6QcVWEBKP44fzvxZEYZsacSyNMGtahyZ00SdbRgM9xaFJzR8VkbE5P/fiw/3AgF4crXmdVZUjlvJhmLpwImTAqGnwbU05noCukevHMS49rzGwPbGqPIGx1sPWNnSqMDGHKh5iRZy5Uj2M3wVWFbIT4PYBYKA1UaYHl7jlZf0zMkSGN4wBXxrg1ChGuilKT+mIoLRPkEG8KiPM53pGgVAEiRtUjefIxwP1DrnadSibTOApxoK+VRKB+i9N9SrhKSn/8Tu0x520E/7qdK28NS3a07uXNHwy7wrAsHxl+jPApe9XPl4ZArPA2/T7Q+a1KZ4O3gXmm2H5QD2ChZo/kys+w+11WsHMdgoAZ92t8vntHTUEvMX6uKc9xmbtlaFyNU5YxUW52sJcTPiOUNiOFO71eJVK47UutwPy7MqHhIOeCiCvtxP8oQBGPZW9STE75avwg5DPjyEKIflrPcjQKSj2CbzsY7x6UZuSvKecDFGDvv39/5k+U+pFTzj8ZSYoJtzz80xl3Sp3s/6i2jaiEZiH2CgzJl2EQcQrbiCsQplObZqjGbR3CYlTSadS++SlUzEivqh9dhO7IynT0iI9GeRcsUWChmkn/9J7ZQf+YIJKUdryjVicEhZYWTDXEkWg/CdqZJ3l27f7OVAHwmPxkw88evCpmwVYIrskzAp/xMslDLqmXW/hJP/jPkSi5qDdfLG3PlTTr/gYjizVO40G71hHPd923hmHmBRd1pp37GB0JiUiHCq4+3CPcAOkxxlFKH3crRikRfrgPhLBaTqu2bI95tPDilKTp+U0qfGZ87xbVqPAO3YQi59JeXDJIjPkrRVMgC/VGQN1wy9DQfUx1M1rLLgFpmDpML6r1heXx9R4+y2EL6yLh6Lwjw7V8KY8W4V5kDIKOmbxcMcvmNeXy532YfK 2Dvd7i2u MqgTNByTOeKr1/+A= 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: On Wed, Jan 18, 2023 at 7:27 AM Jeremi Piotrowski wrote: > > On Wed, Dec 14, 2022 at 01:40:36PM -0600, Michael Roth wrote: > > From: Brijesh Singh > > > > On VMGEXIT, sev_handle_vmgexit() creates a host mapping for the GHCB GPA, > > and unmaps it just before VM-entry. This long-lived GHCB map is used by > > the VMGEXIT handler through accessors such as ghcb_{set_get}_xxx(). > > > > A long-lived GHCB map can cause issue when SEV-SNP is enabled. When > > SEV-SNP is enabled the mapped GPA needs to be protected against a page > > state change. > > > > To eliminate the long-lived GHCB mapping, update the GHCB sync operations > > to explicitly map the GHCB before access and unmap it after access is > > complete. This requires that the setting of the GHCBs sw_exit_info_{1,2} > > fields be done during sev_es_sync_to_ghcb(), so create two new fields in > > the vcpu_svm struct to hold these values when required to be set outside > > of the GHCB mapping. > > > > Signed-off-by: Brijesh Singh > > Signed-off-by: Ashish Kalra > > [mdr: defer per_cpu() assignment and order it with barrier() to fix case > > where kvm_vcpu_map() causes reschedule on different CPU] > > Signed-off-by: Michael Roth > > --- > > arch/x86/kvm/svm/sev.c | 131 ++++++++++++++++++++++++++--------------- > > arch/x86/kvm/svm/svm.c | 18 +++--- > > arch/x86/kvm/svm/svm.h | 24 +++++++- > > 3 files changed, 116 insertions(+), 57 deletions(-) > > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > > index d5c6e48055fb..6ac0cb6e3484 100644 > > --- a/arch/x86/kvm/svm/sev.c > > +++ b/arch/x86/kvm/svm/sev.c > > @@ -2921,15 +2921,40 @@ void sev_free_vcpu(struct kvm_vcpu *vcpu) > > kvfree(svm->sev_es.ghcb_sa); > > } > > > > +static inline int svm_map_ghcb(struct vcpu_svm *svm, struct kvm_host_map *map) > > +{ > > + struct vmcb_control_area *control = &svm->vmcb->control; > > + u64 gfn = gpa_to_gfn(control->ghcb_gpa); > > + > > + if (kvm_vcpu_map(&svm->vcpu, gfn, map)) { > > + /* Unable to map GHCB from guest */ > > + pr_err("error mapping GHCB GFN [%#llx] from guest\n", gfn); > > + return -EFAULT; > > + } > > + > > + return 0; > > +} > > + > > +static inline void svm_unmap_ghcb(struct vcpu_svm *svm, struct kvm_host_map *map) > > +{ > > + kvm_vcpu_unmap(&svm->vcpu, map, true); > > +} > > + > > static void dump_ghcb(struct vcpu_svm *svm) > > { > > - struct ghcb *ghcb = svm->sev_es.ghcb; > > + struct kvm_host_map map; > > unsigned int nbits; > > + struct ghcb *ghcb; > > + > > + if (svm_map_ghcb(svm, &map)) > > + return; > > + > > + ghcb = map.hva; > > dump_ghcb() is called from sev_es_validate_vmgexit() with the ghcb already > mapped. How about passing 'struct kvm_host_map *' (or struct ghcb *) as a > param to avoid double mapping? This also causes a soft lockup, PSC spin lock is already acquired in sev_es_validate_vmgexit. dump_ghcb will try to acquire the same lock again. So a guest can send an invalid ghcb page and cause a host soft lockup. > > > > > /* Re-use the dump_invalid_vmcb module parameter */ > > if (!dump_invalid_vmcb) { > > pr_warn_ratelimited("set kvm_amd.dump_invalid_vmcb=1 to dump internal KVM state.\n"); > > - return; > > + goto e_unmap; > > } > > > > nbits = sizeof(ghcb->save.valid_bitmap) * 8; > > @@ -2944,12 +2969,21 @@ static void dump_ghcb(struct vcpu_svm *svm) > > pr_err("%-20s%016llx is_valid: %u\n", "sw_scratch", > > ghcb->save.sw_scratch, ghcb_sw_scratch_is_valid(ghcb)); > > pr_err("%-20s%*pb\n", "valid_bitmap", nbits, ghcb->save.valid_bitmap); > > + > > +e_unmap: > > + svm_unmap_ghcb(svm, &map); > > } > > > > -static void sev_es_sync_to_ghcb(struct vcpu_svm *svm) > > +static bool sev_es_sync_to_ghcb(struct vcpu_svm *svm) > > { > > struct kvm_vcpu *vcpu = &svm->vcpu; > > - struct ghcb *ghcb = svm->sev_es.ghcb; > > + struct kvm_host_map map; > > + struct ghcb *ghcb; > > + > > + if (svm_map_ghcb(svm, &map)) > > + return false; > > + > > + ghcb = map.hva; > > > > /* > > * The GHCB protocol so far allows for the following data > > @@ -2963,13 +2997,24 @@ static void sev_es_sync_to_ghcb(struct vcpu_svm *svm) > > ghcb_set_rbx(ghcb, vcpu->arch.regs[VCPU_REGS_RBX]); > > ghcb_set_rcx(ghcb, vcpu->arch.regs[VCPU_REGS_RCX]); > > ghcb_set_rdx(ghcb, vcpu->arch.regs[VCPU_REGS_RDX]); > > + > > + /* > > + * Copy the return values from the exit_info_{1,2}. > > + */ > > + ghcb_set_sw_exit_info_1(ghcb, svm->sev_es.ghcb_sw_exit_info_1); > > + ghcb_set_sw_exit_info_2(ghcb, svm->sev_es.ghcb_sw_exit_info_2); > > + > > + trace_kvm_vmgexit_exit(svm->vcpu.vcpu_id, ghcb); > > + > > + svm_unmap_ghcb(svm, &map); > > + > > + return true; > > } > > > > -static void sev_es_sync_from_ghcb(struct vcpu_svm *svm) > > +static void sev_es_sync_from_ghcb(struct vcpu_svm *svm, struct ghcb *ghcb) > > { > > struct vmcb_control_area *control = &svm->vmcb->control; > > struct kvm_vcpu *vcpu = &svm->vcpu; > > - struct ghcb *ghcb = svm->sev_es.ghcb; > > u64 exit_code; > > > > /* > > @@ -3013,20 +3058,25 @@ static void sev_es_sync_from_ghcb(struct vcpu_svm *svm) > > memset(ghcb->save.valid_bitmap, 0, sizeof(ghcb->save.valid_bitmap)); > > } > > > > -static int sev_es_validate_vmgexit(struct vcpu_svm *svm) > > +static int sev_es_validate_vmgexit(struct vcpu_svm *svm, u64 *exit_code) > > { > > - struct kvm_vcpu *vcpu; > > + struct kvm_vcpu *vcpu = &svm->vcpu; > > + struct kvm_host_map map; > > struct ghcb *ghcb; > > - u64 exit_code; > > u64 reason; > > > > - ghcb = svm->sev_es.ghcb; > > + if (svm_map_ghcb(svm, &map)) > > + return -EFAULT; > > + > > + ghcb = map.hva; > > + > > + trace_kvm_vmgexit_enter(vcpu->vcpu_id, ghcb); > > > > /* > > * Retrieve the exit code now even though it may not be marked valid > > * as it could help with debugging. > > */ > > - exit_code = ghcb_get_sw_exit_code(ghcb); > > + *exit_code = ghcb_get_sw_exit_code(ghcb); > > > > /* Only GHCB Usage code 0 is supported */ > > if (ghcb->ghcb_usage) { > > @@ -3119,6 +3169,9 @@ static int sev_es_validate_vmgexit(struct vcpu_svm *svm) > > goto vmgexit_err; > > } > > > > + sev_es_sync_from_ghcb(svm, ghcb); > > + > > + svm_unmap_ghcb(svm, &map); > > return 0; > > > > vmgexit_err: > > @@ -3129,10 +3182,10 @@ static int sev_es_validate_vmgexit(struct vcpu_svm *svm) > > ghcb->ghcb_usage); > > } else if (reason == GHCB_ERR_INVALID_EVENT) { > > vcpu_unimpl(vcpu, "vmgexit: exit code %#llx is not valid\n", > > - exit_code); > > + *exit_code); > > } else { > > vcpu_unimpl(vcpu, "vmgexit: exit code %#llx input is not valid\n", > > - exit_code); > > + *exit_code); > > dump_ghcb(svm); > > } > > > > @@ -3142,6 +3195,8 @@ static int sev_es_validate_vmgexit(struct vcpu_svm *svm) > > ghcb_set_sw_exit_info_1(ghcb, 2); > > ghcb_set_sw_exit_info_2(ghcb, reason); > > > > + svm_unmap_ghcb(svm, &map); > > + > > /* Resume the guest to "return" the error code. */ > > return 1; > > } >