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=unavailable 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 A550FC4646B for ; Wed, 26 Jun 2019 05:31:20 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 3590E2080C for ; Wed, 26 Jun 2019 05:31:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3590E2080C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 72BBF4A50F; Wed, 26 Jun 2019 01:31:19 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpI4o46ZSi93; Wed, 26 Jun 2019 01:31:18 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 235B34A4FC; Wed, 26 Jun 2019 01:31:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 09BAD4A4C0 for ; Wed, 26 Jun 2019 01:31:17 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRHlAbpYh8kB for ; Wed, 26 Jun 2019 01:31:15 -0400 (EDT) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 168A54A4BE for ; Wed, 26 Jun 2019 01:31:15 -0400 (EDT) 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 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-Language: en-US Cc: Andre Przywara , Dave Martin X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm