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 2DAF4C433F5 for ; Wed, 9 Feb 2022 16:41:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237353AbiBIQlG (ORCPT ); Wed, 9 Feb 2022 11:41:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235192AbiBIQlF (ORCPT ); Wed, 9 Feb 2022 11:41:05 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D5AC6C0612BE for ; Wed, 9 Feb 2022 08:41:07 -0800 (PST) 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 975E3ED1; Wed, 9 Feb 2022 08:41:07 -0800 (PST) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BF7393F70D; Wed, 9 Feb 2022 08:41:04 -0800 (PST) Date: Wed, 9 Feb 2022 16:41:20 +0000 From: Alexandru Elisei To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , Jintack Lim , Haibo Xu , Ganapatrao Kulkarni , Chase Conklin , "Russell King (Oracle)" , James Morse , Suzuki K Poulose , karl.heubaum@oracle.com, mihai.carabas@oracle.com, miguel.luis@oracle.com, kernel-team@android.com Subject: Re: [PATCH v6 30/64] KVM: arm64: nv: Configure HCR_EL2 for nested virtualization Message-ID: References: <20220128121912.509006-1-maz@kernel.org> <20220128121912.509006-31-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220128121912.509006-31-maz@kernel.org> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Hi, On Fri, Jan 28, 2022 at 12:18:38PM +0000, 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 748c2b068d4e..d913c3fb5665 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) > #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 1e6a00e7bfb3..28845f907cfc 100644 > --- a/arch/arm64/kvm/hyp/vhe/switch.c > +++ b/arch/arm64/kvm/hyp/vhe/switch.c > @@ -35,9 +35,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_is_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 That's confusing, because FEAT_NV is available from v8.3 and newer. > + * the EL1 virtual memory control register accesses. > + */ Wasn't the purpose of comment to explain why something is done instead of what something does? The bits are explained in the Arm ARM. How about something like this instead: "A hypervisor running in non-VHE mode writes to EL1 the memory control registers when preparing to run a guest or the host at EL1. Since virtual EL2 is emulated on top of physical EL1, allowing the L1 guest hypervisor to access the registers directly would lead to the L1 guest inadvertently corrupting its own state. The NV1 bit is set to trap accesses to the registers which aren't controlled by the TVM and TRVM bits, and to change to translation table format used by the EL1&0 translation regime format to the EL2 translation regime format, which is what the L1 guest hypervisor running with E2H = 0 expects when it creates the tables". > + 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); Nitpick: I think it would be better to name this variable virtual_hcr_el2, because vhcr_el2 looks like a valid register name. Thanks, Alex > + > + vhcr_el2 &= ~HCR_GUEST_NV_FILTER_FLAGS; > + > + /* > + * We already set TVM to handle set/way cache maint > + * ops traps, this somewhat collides with the nested > + * virt trapping for nVHE. So turn this off for now > + * here, in the hope that VHE guests won't ever do this. > + * TODO: find out whether it's worth to support both > + * cases at the same time. > + */ > + hcr &= ~HCR_TVM; > + > + hcr |= vhcr_el2 & (HCR_TVM | HCR_TRVM); > + } > + } > > ___activate_traps(vcpu, hcr); > > -- > 2.30.2 > 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 mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AAD7C433EF for ; Wed, 9 Feb 2022 16:41:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C112649EDE; Wed, 9 Feb 2022 11:41:12 -0500 (EST) 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 wGJyQpERZ18Q; Wed, 9 Feb 2022 11:41:11 -0500 (EST) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 149C249ED7; Wed, 9 Feb 2022 11:41:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C46F549E49 for ; Wed, 9 Feb 2022 11:41:09 -0500 (EST) 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 MwkUyg+Chsl4 for ; Wed, 9 Feb 2022 11:41:08 -0500 (EST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 25CA849E44 for ; Wed, 9 Feb 2022 11:41:08 -0500 (EST) 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 975E3ED1; Wed, 9 Feb 2022 08:41:07 -0800 (PST) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BF7393F70D; Wed, 9 Feb 2022 08:41:04 -0800 (PST) Date: Wed, 9 Feb 2022 16:41:20 +0000 From: Alexandru Elisei To: Marc Zyngier Subject: Re: [PATCH v6 30/64] KVM: arm64: nv: Configure HCR_EL2 for nested virtualization Message-ID: References: <20220128121912.509006-1-maz@kernel.org> <20220128121912.509006-31-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220128121912.509006-31-maz@kernel.org> Cc: kernel-team@android.com, kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , Chase Conklin , kvmarm@lists.cs.columbia.edu, mihai.carabas@oracle.com, Ganapatrao Kulkarni , "Russell King \(Oracle\)" , linux-arm-kernel@lists.infradead.org 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 Hi, On Fri, Jan 28, 2022 at 12:18:38PM +0000, 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 748c2b068d4e..d913c3fb5665 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) > #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 1e6a00e7bfb3..28845f907cfc 100644 > --- a/arch/arm64/kvm/hyp/vhe/switch.c > +++ b/arch/arm64/kvm/hyp/vhe/switch.c > @@ -35,9 +35,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_is_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 That's confusing, because FEAT_NV is available from v8.3 and newer. > + * the EL1 virtual memory control register accesses. > + */ Wasn't the purpose of comment to explain why something is done instead of what something does? The bits are explained in the Arm ARM. How about something like this instead: "A hypervisor running in non-VHE mode writes to EL1 the memory control registers when preparing to run a guest or the host at EL1. Since virtual EL2 is emulated on top of physical EL1, allowing the L1 guest hypervisor to access the registers directly would lead to the L1 guest inadvertently corrupting its own state. The NV1 bit is set to trap accesses to the registers which aren't controlled by the TVM and TRVM bits, and to change to translation table format used by the EL1&0 translation regime format to the EL2 translation regime format, which is what the L1 guest hypervisor running with E2H = 0 expects when it creates the tables". > + 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); Nitpick: I think it would be better to name this variable virtual_hcr_el2, because vhcr_el2 looks like a valid register name. Thanks, Alex > + > + vhcr_el2 &= ~HCR_GUEST_NV_FILTER_FLAGS; > + > + /* > + * We already set TVM to handle set/way cache maint > + * ops traps, this somewhat collides with the nested > + * virt trapping for nVHE. So turn this off for now > + * here, in the hope that VHE guests won't ever do this. > + * TODO: find out whether it's worth to support both > + * cases at the same time. > + */ > + hcr &= ~HCR_TVM; > + > + hcr |= vhcr_el2 & (HCR_TVM | HCR_TRVM); > + } > + } > > ___activate_traps(vcpu, hcr); > > -- > 2.30.2 > _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 27A66C433F5 for ; Wed, 9 Feb 2022 16:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LLqfzHwHNB3Wp1EJnN6O8k3+MzUT7QhAWXYq/SPV3TY=; b=onMct4N0UMdS3I rvKza8zoJki51bX4Wcgd5EFXKNdtGKF+eBcQeqkM9x0mQTR6PTnC1r9yRSjUgLNwb5JevwbXOUKiI 7yWUE8IqEhiCaZhzcvE6gByBeHneVeyGL5r47gB7a9XBofjDotCvdsxJw52M25J6aBVvgDaBMZsA1 hZW+//smZZfsxXLDk7CLdXbIyzLnuNhQmopjw3xgm5ov6KVDT8BFnzHjbl+Li9aLAzUMbGL8CrbgE z0Lqwrx+a0GMP6LyNVp5SyS91G5goCzkwLZmFB4TyKkOFoyyHYU9M6eq1n2yEFZiP18h8KWfrREf5 uuluiY46foKuVBJKjlgQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nHq1r-000s6G-9k; Wed, 09 Feb 2022 16:41:15 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nHq1n-000s4H-1x for linux-arm-kernel@lists.infradead.org; Wed, 09 Feb 2022 16:41:12 +0000 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 975E3ED1; Wed, 9 Feb 2022 08:41:07 -0800 (PST) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BF7393F70D; Wed, 9 Feb 2022 08:41:04 -0800 (PST) Date: Wed, 9 Feb 2022 16:41:20 +0000 From: Alexandru Elisei To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Andre Przywara , Christoffer Dall , Jintack Lim , Haibo Xu , Ganapatrao Kulkarni , Chase Conklin , "Russell King (Oracle)" , James Morse , Suzuki K Poulose , karl.heubaum@oracle.com, mihai.carabas@oracle.com, miguel.luis@oracle.com, kernel-team@android.com Subject: Re: [PATCH v6 30/64] KVM: arm64: nv: Configure HCR_EL2 for nested virtualization Message-ID: References: <20220128121912.509006-1-maz@kernel.org> <20220128121912.509006-31-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220128121912.509006-31-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220209_084111_242589_2B0E2593 X-CRM114-Status: GOOD ( 30.49 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Fri, Jan 28, 2022 at 12:18:38PM +0000, 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 748c2b068d4e..d913c3fb5665 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) > #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 1e6a00e7bfb3..28845f907cfc 100644 > --- a/arch/arm64/kvm/hyp/vhe/switch.c > +++ b/arch/arm64/kvm/hyp/vhe/switch.c > @@ -35,9 +35,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_is_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 That's confusing, because FEAT_NV is available from v8.3 and newer. > + * the EL1 virtual memory control register accesses. > + */ Wasn't the purpose of comment to explain why something is done instead of what something does? The bits are explained in the Arm ARM. How about something like this instead: "A hypervisor running in non-VHE mode writes to EL1 the memory control registers when preparing to run a guest or the host at EL1. Since virtual EL2 is emulated on top of physical EL1, allowing the L1 guest hypervisor to access the registers directly would lead to the L1 guest inadvertently corrupting its own state. The NV1 bit is set to trap accesses to the registers which aren't controlled by the TVM and TRVM bits, and to change to translation table format used by the EL1&0 translation regime format to the EL2 translation regime format, which is what the L1 guest hypervisor running with E2H = 0 expects when it creates the tables". > + 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); Nitpick: I think it would be better to name this variable virtual_hcr_el2, because vhcr_el2 looks like a valid register name. Thanks, Alex > + > + vhcr_el2 &= ~HCR_GUEST_NV_FILTER_FLAGS; > + > + /* > + * We already set TVM to handle set/way cache maint > + * ops traps, this somewhat collides with the nested > + * virt trapping for nVHE. So turn this off for now > + * here, in the hope that VHE guests won't ever do this. > + * TODO: find out whether it's worth to support both > + * cases at the same time. > + */ > + hcr &= ~HCR_TVM; > + > + hcr |= vhcr_el2 & (HCR_TVM | HCR_TRVM); > + } > + } > > ___activate_traps(vcpu, hcr); > > -- > 2.30.2 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel