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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9F49C433EF for ; Wed, 13 Oct 2021 17:57:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5F70F60E0C for ; Wed, 13 Oct 2021 17:57:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5F70F60E0C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E38FA6B0071; Wed, 13 Oct 2021 13:57:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE8336B0072; Wed, 13 Oct 2021 13:57:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD7A8900002; Wed, 13 Oct 2021 13:57:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id BFB1B6B0071 for ; Wed, 13 Oct 2021 13:57:26 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7DD1B3260A for ; Wed, 13 Oct 2021 17:57:26 +0000 (UTC) X-FDA: 78692171292.02.18D973D Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf22.hostedemail.com (Postfix) with ESMTP id 8D7F71901 for ; Wed, 13 Oct 2021 17:57:25 +0000 (UTC) Received: by mail-pg1-f174.google.com with SMTP id e65so686267pgc.5 for ; Wed, 13 Oct 2021 10:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nYRMF9NLZlIYvCMUzNz88c0C/LYzcmp0YC6IScl8K1M=; b=NgG+UbKFXQEeJU+vxIERcV8ISM8vK2GCSApZ6LVvO8Ca4vuob2erFTer8Pjy+LmOlx oQNqfc4GDoSc8kBYl2UQuoJCdCPDunS7oChSW89ZvBC0D5H5CPPmiL+ueA8J+Mm8lR4T hJJlty1d2LjuoUIDYuT/iG0qDt97u16L7UQrJg/LobgP9fw0Bk0K06xWDbzC+nFmvUR9 e05rVnnoZXh6SEoemSALmKQmezFDLIf1O9MDVP1nYpxigjBeIyWXGs/Fr4gJGcrY3APT lQZGOxPee5B/4281bZcijDSsReBobfryrTBKyzHczFPs3pwj76Rw2G3+tM++U5ijVdOF hMgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nYRMF9NLZlIYvCMUzNz88c0C/LYzcmp0YC6IScl8K1M=; b=LoJLraIgzAy2u3hR5uorRggx4spBk7mmEM8/Q03tSU0c4002WqeqAb8ytneoXufwZQ jv/sEMUD1d1dpvgxdM+Elc+LriDWOKMWDJ+gfl3m6yUIYsmMsesHJCkDI8lgC0R6shGD EtgrEjc9Q8lnm+uIOly709QekEkc1hkq2vtms5mkfsJ+Febyu9BCj2RQVvU+BOhT3U6G OYv+DW4xdEGFOD9NHG9p1G95bKqZMQhihnO7xSXR5RWq1QNk5RBjjnmhc4HXyW5aBOLx g9/+zX42KRuHTX+U9/8SeMiDmlZn1+IBNIBA2kg23n7Bf5F7SK2dtLbDAL0eaHx5Nslv heeA== X-Gm-Message-State: AOAM532wQHt62W6xhV+eZjSAWfI3fFaYjO9IalxZWwrKeUsj9q6BabUQ RDUOR88OOXIGz65EGJm/GzVvag== X-Google-Smtp-Source: ABdhPJyMiVGmUTYUtcdh7bcTvHq4WhqYjQCakcIXj/dCcEixSLcina/nmF5U4pACwtO5b1z16bv7/Q== X-Received: by 2002:a05:6a00:1344:b0:44c:4cd7:4d4b with SMTP id k4-20020a056a00134400b0044c4cd74d4bmr795524pfu.50.1634147844761; Wed, 13 Oct 2021 10:57:24 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id z24sm180698pgu.54.2021.10.13.10.57.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Oct 2021 10:57:24 -0700 (PDT) Date: Wed, 13 Oct 2021 17:57:20 +0000 From: Sean Christopherson To: Brijesh Singh Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH Part2 v5 41/45] KVM: SVM: Add support to handle the RMP nested page fault Message-ID: References: <20210820155918.7518-1-brijesh.singh@amd.com> <20210820155918.7518-42-brijesh.singh@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210820155918.7518-42-brijesh.singh@amd.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 8D7F71901 X-Stat-Signature: 5fcyyp36pfuqs37q5qi951nm8qjgkybo Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=NgG+UbKF; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of seanjc@google.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=seanjc@google.com X-HE-Tag: 1634147845-97416 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 Fri, Aug 20, 2021, Brijesh Singh wrote: > When SEV-SNP is enabled in the guest, the hardware places restrictions on > all memory accesses based on the contents of the RMP table. When hardware > encounters RMP check failure caused by the guest memory access it raises > the #NPF. The error code contains additional information on the access > type. See the APM volume 2 for additional information. > > Signed-off-by: Brijesh Singh > --- > arch/x86/kvm/svm/sev.c | 76 ++++++++++++++++++++++++++++++++++++++++++ > arch/x86/kvm/svm/svm.c | 14 +++++--- > arch/x86/kvm/svm/svm.h | 1 + > 3 files changed, 87 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index 65b578463271..712e8907bc39 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -3651,3 +3651,79 @@ void sev_post_unmap_gfn(struct kvm *kvm, gfn_t gfn, kvm_pfn_t pfn, int token) > > srcu_read_unlock(&sev->psc_srcu, token); > } > + > +void handle_rmp_page_fault(struct kvm_vcpu *vcpu, gpa_t gpa, u64 error_code) > +{ > + int rmp_level, npt_level, rc, assigned; Really silly nit: can you use 'r' or 'ret' instead of 'rc'? Outside of the emulator, which should never be the gold standard for code ;-), 'rc' isn't used in x86 KVM. > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 3784d389247b..3ba62f21b113 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -1933,15 +1933,21 @@ static int pf_interception(struct kvm_vcpu *vcpu) > static int npf_interception(struct kvm_vcpu *vcpu) > { > struct vcpu_svm *svm = to_svm(vcpu); > + int rc; > > u64 fault_address = svm->vmcb->control.exit_info_2; > u64 error_code = svm->vmcb->control.exit_info_1; > > trace_kvm_page_fault(fault_address, error_code); > - return kvm_mmu_page_fault(vcpu, fault_address, error_code, > - static_cpu_has(X86_FEATURE_DECODEASSISTS) ? > - svm->vmcb->control.insn_bytes : NULL, > - svm->vmcb->control.insn_len); > + rc = kvm_mmu_page_fault(vcpu, fault_address, error_code, > + static_cpu_has(X86_FEATURE_DECODEASSISTS) ? > + svm->vmcb->control.insn_bytes : NULL, > + svm->vmcb->control.insn_len); > + > + if (error_code & PFERR_GUEST_RMP_MASK) Don't think it will matter in the end, but shouldn't this consult 'rc' before diving into RMP handling? > + handle_rmp_page_fault(vcpu, fault_address, error_code); Similar to my comments on the PSC patches, I think this is backwards. The MMU should provide the control logic to convert between private and shared, and vendor code should only get involved when there are side effects from the conversion. Once I've made a dent in my review backlog, I'll fiddle with this and some of the other MMU interactions, and hopefully come up with a workable sketch for the MMU stuff. Yell at me if you haven't gotten an update by Wednesday or so.