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 X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49816C4646B for ; Wed, 26 Jun 2019 05:31:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2DE7F2080C for ; Wed, 26 Jun 2019 05:31:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726416AbfFZFbP (ORCPT ); Wed, 26 Jun 2019 01:31:15 -0400 Received: from foss.arm.com ([217.140.110.172]:54342 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725536AbfFZFbP (ORCPT ); Wed, 26 Jun 2019 01:31:15 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 53F592B; Tue, 25 Jun 2019 22:31:14 -0700 (PDT) Received: from [10.37.8.13] (unknown [10.37.8.13]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DA5A33F246; Tue, 25 Jun 2019 22:33:01 -0700 (PDT) Subject: Re: [PATCH 26/59] KVM: arm64: nv: Respect the virtual HCR_EL2.NV bit setting To: Marc Zyngier , linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org Cc: Andre Przywara , Christoffer Dall , Dave Martin , Jintack Lim , James Morse , Suzuki K Poulose References: <20190621093843.220980-1-marc.zyngier@arm.com> <20190621093843.220980-27-marc.zyngier@arm.com> From: Julien Thierry Message-ID: <8ad1b436-9325-2abb-648d-2cd3a3c9b113@arm.com> Date: Wed, 26 Jun 2019 06:31:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190621093843.220980-27-marc.zyngier@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 06/21/2019 10:38 AM, Marc Zyngier wrote: > From: Jintack Lim > > Forward traps due to HCR_EL2.NV bit to the virtual EL2 if they are not > coming from the virtual EL2 and the virtual HCR_EL2.NV bit is set. > > In addition to EL2 register accesses, setting NV bit will also make EL12 > register accesses trap to EL2. To emulate this for the virtual EL2, > forword traps due to EL12 register accessses to the virtual EL2 if the > virtual HCR_EL2.NV bit is set. > > This is for recursive nested virtualization. > > Signed-off-by: Jintack Lim > [Moved code to emulate-nested.c] > Signed-off-by: Christoffer Dall > Signed-off-by: Marc Zyngier > --- > arch/arm64/include/asm/kvm_arm.h | 1 + > arch/arm64/include/asm/kvm_nested.h | 2 ++ > arch/arm64/kvm/emulate-nested.c | 28 ++++++++++++++++++++++++++++ > arch/arm64/kvm/handle_exit.c | 6 ++++++ > arch/arm64/kvm/sys_regs.c | 18 ++++++++++++++++++ > 5 files changed, 55 insertions(+) > > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h > index 48e15af2bece..d21486274eeb 100644 > --- a/arch/arm64/include/asm/kvm_arm.h > +++ b/arch/arm64/include/asm/kvm_arm.h > @@ -24,6 +24,7 @@ > > /* Hyp Configuration Register (HCR) bits */ > #define HCR_FWB (UL(1) << 46) > +#define HCR_NV (UL(1) << 42) > #define HCR_API (UL(1) << 41) > #define HCR_APK (UL(1) << 40) > #define HCR_TEA (UL(1) << 37) > diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h > index 645e5e11b749..61e71d0d2151 100644 > --- a/arch/arm64/include/asm/kvm_nested.h > +++ b/arch/arm64/include/asm/kvm_nested.h > @@ -11,5 +11,7 @@ static inline bool nested_virt_in_use(const struct kvm_vcpu *vcpu) > } > > int handle_wfx_nested(struct kvm_vcpu *vcpu, bool is_wfe); > +extern bool forward_traps(struct kvm_vcpu *vcpu, u64 control_bit); > +extern bool forward_nv_traps(struct kvm_vcpu *vcpu); > > #endif /* __ARM64_KVM_NESTED_H */ > diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c > index f829b8b04dc8..c406fd688b9f 100644 > --- a/arch/arm64/kvm/emulate-nested.c > +++ b/arch/arm64/kvm/emulate-nested.c > @@ -24,6 +24,27 @@ > > #include "trace.h" > > +bool forward_traps(struct kvm_vcpu *vcpu, u64 control_bit) Should this one be static? > +{ > + bool control_bit_set; > + > + if (!nested_virt_in_use(vcpu)) > + return false; > + > + control_bit_set = __vcpu_sys_reg(vcpu, HCR_EL2) & control_bit; > + if (!vcpu_mode_el2(vcpu) && control_bit_set) { > + kvm_inject_nested_sync(vcpu, kvm_vcpu_get_hsr(vcpu)); > + return true; > + } > + return false; > +} > + > +bool forward_nv_traps(struct kvm_vcpu *vcpu) > +{ > + return forward_traps(vcpu, HCR_NV); > +} > + > + > /* This is borrowed from get_except_vector in inject_fault.c */ > static u64 get_el2_except_vector(struct kvm_vcpu *vcpu, > enum exception_type type) > @@ -55,6 +76,13 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu) > u64 spsr, elr, mode; > bool direct_eret; > > + /* > + * Forward this trap to the virtual EL2 if the virtual > + * HCR_EL2.NV bit is set and this is coming from !EL2. > + */ > + if (forward_nv_traps(vcpu)) > + return; > + > /* > * Going through the whole put/load motions is a waste of time > * if this is a VHE guest hypervisor returning to its own > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > index 39602a4c1d61..7e8b1ec1d251 100644 > --- a/arch/arm64/kvm/handle_exit.c > +++ b/arch/arm64/kvm/handle_exit.c > @@ -72,6 +72,12 @@ static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run) > { > int ret; > > + /* > + * Forward this trapped smc instruction to the virtual EL2. > + */ > + if ((vcpu_read_sys_reg(vcpu, HCR_EL2) & HCR_TSC) && forward_nv_traps(vcpu)) Not sure I understand why this would be only when the guest hyp also has NV set. If the guest hyp requested to trap smc instructions and that we received one while in vel1, shouldn't we always forward it to the guest hyp to let it implement the smc response the way it wants? Cheers, Julien