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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC32AC433F5 for ; Tue, 4 Jan 2022 09:40:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230048AbiADJkF (ORCPT ); Tue, 4 Jan 2022 04:40:05 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:43830 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229677AbiADJkE (ORCPT ); Tue, 4 Jan 2022 04:40:04 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 927ABB8118A for ; Tue, 4 Jan 2022 09:40:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23A42C36AF3; Tue, 4 Jan 2022 09:40:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641289202; bh=2ikLkM64NuU+jo6o2U74nnzEnIhFw8r3SMpbAO9wtxs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Gze5ghq60O85ROITI9idjc1Mui0rvCmzO3xK1D2wm3XTJF+ADcoSJwzjGp3zsV4Br QduvcIf21gvTNG5CLHHRkg3fI762PTwP3newC6o5uPMFjo0fBfuXmCABj/L8g6J+xd 0BuWF/BR7MxJZVBMns/s9AmucsLJ50ESjLsp17sQ5EKms6xqFbIGVvjCt83Ct6bUD/ VBVnSoUY9K7GaqKZ0x46uAkWi+i4Jp3W++oYR0vQXh10CjjUNQOLy70jqe4j020ufK 5J00x2d0efOqOgAmRFZ5mYeZdrYH6Ih/7kvIzCWHZgCAsJSHddFiNz45P4xT9AQuo8 S81I564VJt/2A== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n4gIS-00FsEg-4A; Tue, 04 Jan 2022 09:40:00 +0000 Date: Tue, 04 Jan 2022 09:39:59 +0000 Message-ID: <87o84rvnyo.wl-maz@kernel.org> From: Marc Zyngier To: Ganapatrao Kulkarni Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , Jintack Lim , Haibo Xu , James Morse , Suzuki K Poulose , Alexandru Elisei , kernel-team@android.com Subject: Re: [PATCH v5 34/69] KVM: arm64: nv: Configure HCR_EL2 for nested virtualization In-Reply-To: References: <20211129200150.351436-1-maz@kernel.org> <20211129200150.351436-35-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: gankulkarni@os.amperecomputing.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, andre.przywara@arm.com, christoffer.dall@arm.com, jintack@cs.columbia.edu, haibo.xu@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com, alexandru.elisei@arm.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, 04 Jan 2022 08:53:42 +0000, Ganapatrao Kulkarni wrote: > > > > On 30-11-2021 01:31 am, Marc Zyngier wrote: > > From: Jintack Lim > > > > We enable nested virtualization by setting the HCR NV and NV1 bit. > > > > When the virtual E2H bit is set, we can support EL2 register accesses > > via EL1 registers from the virtual EL2 by doing trap-and-emulate. A > > better alternative, however, is to allow the virtual EL2 to access EL2 > > register states without trap. This can be easily achieved by not traping > > EL1 registers since those registers already have EL2 register states. > > > > Signed-off-by: Jintack Lim > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/kvm_arm.h | 1 + > > arch/arm64/kvm/hyp/vhe/switch.c | 38 +++++++++++++++++++++++++++++--- > > 2 files changed, 36 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h > > index 68af5509e4b0..b8a0d410035b 100644 > > --- a/arch/arm64/include/asm/kvm_arm.h > > +++ b/arch/arm64/include/asm/kvm_arm.h > > @@ -87,6 +87,7 @@ > > HCR_BSU_IS | HCR_FB | HCR_TACR | \ > > HCR_AMO | HCR_SWIO | HCR_TIDCP | HCR_RW | HCR_TLOR | \ > > HCR_FMO | HCR_IMO | HCR_PTW ) > > +#define HCR_GUEST_NV_FILTER_FLAGS (HCR_ATA | HCR_API | HCR_APK | HCR_RW) > > #define HCR_VIRT_EXCP_MASK (HCR_VSE | HCR_VI | HCR_VF) > > #define HCR_HOST_NVHE_FLAGS (HCR_RW | HCR_API | HCR_APK | HCR_ATA) > > #define HCR_HOST_NVHE_PROTECTED_FLAGS (HCR_HOST_NVHE_FLAGS | HCR_TSC) > > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c > > index 57f43e607819..da80c969e623 100644 > > --- a/arch/arm64/kvm/hyp/vhe/switch.c > > +++ b/arch/arm64/kvm/hyp/vhe/switch.c > > @@ -36,9 +36,41 @@ static void __activate_traps(struct kvm_vcpu *vcpu) > > u64 hcr = vcpu->arch.hcr_el2; > > u64 val; > > - /* Trap VM sysreg accesses if an EL2 guest is not using > > VHE. */ > > - if (vcpu_mode_el2(vcpu) && !vcpu_el2_e2h_is_set(vcpu)) > > - hcr |= HCR_TVM | HCR_TRVM; > > + if (is_hyp_ctxt(vcpu)) { > > + hcr |= HCR_NV; > > + > > + if (!vcpu_el2_e2h_is_set(vcpu)) { > > + /* > > + * For a guest hypervisor on v8.0, trap and emulate > > + * the EL1 virtual memory control register accesses. > > + */ > > + hcr |= HCR_TVM | HCR_TRVM | HCR_NV1; > > + } else { > > + /* > > + * For a guest hypervisor on v8.1 (VHE), allow to > > + * access the EL1 virtual memory control registers > > + * natively. These accesses are to access EL2 register > > + * states. > > + * Note that we still need to respect the virtual > > + * HCR_EL2 state. > > + */ > > + u64 vhcr_el2 = __vcpu_sys_reg(vcpu, HCR_EL2); > > + > > + vhcr_el2 &= ~HCR_GUEST_NV_FILTER_FLAGS; > > Why HCR_RW is cleared here, May I know please? Good question. That's clearly a leftover from an early rework. It really doesn't matter, as we are merging the guest's configuration into the host's, and the host already has HCR_EL2.RW set. What HCR_GUEST_NV_FILTER_FLAGS should contain is only the bits we don't want to deal with at this stage of the NV support. I'll fix that for the next round. Thanks, M. -- Without deviation from the norm, progress is not possible.