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 D71D7C4332F for ; Wed, 9 Feb 2022 16:57:59 +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=ofje/KYzYxZsaeeLyLF25mR2rfv9D3k2eHq/p68/5Kc=; b=BZkfZtFpbONuQk 1O419DwRNj/NqrEuk5gTaGUQ8LEAklMvHEPY7tcTcbZCUV+XJYfpEA4EE1e04nEj75mOg7Mn8OTTX +W6pSA2OO4lNCzrhRTiqCx4QyLtafMsj2ue+9d42NU4GG/WhTFhpBoMqTYKPbxwdjt3i5LZlU9aYc BnRYXvM3Qc567Fy32WpX56YcpuO135nmlyOl25mQ8EyueIs15uiz0aTzDQacXmpkwSp5jYA8sYmBm iVHT1pacUGojSbjeheT8aEkySYWI9/Jhvv9R1mECznb0+qoU8rOF0T8vEjw3Hz6VfJ0YxNwXMKDjq HUS6MiKPa8TFOip902hA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nHqGk-000tZD-8C; Wed, 09 Feb 2022 16:56:38 +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 1nHqGg-000tSb-Lk for linux-arm-kernel@lists.infradead.org; Wed, 09 Feb 2022 16:56:36 +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 476B0ED1; Wed, 9 Feb 2022 08:56:32 -0800 (PST) Received: from monolith.localdoman (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 12B833F73B; Wed, 9 Feb 2022 08:56:28 -0800 (PST) Date: Wed, 9 Feb 2022 16:56:48 +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 31/64] KVM: arm64: nv: Only toggle cache for virtual EL2 when SCTLR_EL2 changes Message-ID: References: <20220128121912.509006-1-maz@kernel.org> <20220128121912.509006-32-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220128121912.509006-32-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220209_085634_835091_2938DC16 X-CRM114-Status: GOOD ( 24.83 ) 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 Marc, On Fri, Jan 28, 2022 at 12:18:39PM +0000, Marc Zyngier wrote: > From: Christoffer Dall > > So far we were flushing almost the entire universe whenever a VM would > load/unload the SCTLR_EL1 and the two versions of that register had > different MMU enabled settings. This turned out to be so slow that it > prevented forward progress for a nested VM, because a scheduler timer > tick interrupt would always be pending when we reached the nested VM. > > To avoid this problem, we consider the SCTLR_EL2 when evaluating if > caches are on or off when entering virtual EL2 (because this is the > value that we end up shadowing onto the hardware EL1 register). > > Signed-off-by: Christoffer Dall > Signed-off-by: Jintack Lim > Signed-off-by: Marc Zyngier > --- > arch/arm64/include/asm/kvm_mmu.h | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h > index 81839e9a8a24..1b314b2a69bc 100644 > --- a/arch/arm64/include/asm/kvm_mmu.h > +++ b/arch/arm64/include/asm/kvm_mmu.h > @@ -115,6 +115,7 @@ alternative_cb_end > #include > #include > #include > +#include > > void kvm_update_va_mask(struct alt_instr *alt, > __le32 *origptr, __le32 *updptr, int nr_inst); > @@ -187,7 +188,10 @@ struct kvm; > > static inline bool vcpu_has_cache_enabled(struct kvm_vcpu *vcpu) > { > - return (vcpu_read_sys_reg(vcpu, SCTLR_EL1) & 0b101) == 0b101; > + if (vcpu_is_el2(vcpu)) > + return (__vcpu_sys_reg(vcpu, SCTLR_EL2) & 0b101) == 0b101; > + else > + return (vcpu_read_sys_reg(vcpu, SCTLR_EL1) & 0b101) == 0b101; Might be more readable if instead of 0b101 KVM would use defines, something like: static inline bool vcpu_has_cache_enabled(struct kvm_vcpu *vcpu) { - return (vcpu_read_sys_reg(vcpu, SCTLR_EL1) & 0b101) == 0b101; + u64 cache_bits = SCTLR_ELx_M | SCTLR_ELx_C; + + if (vcpu_is_el2(vcpu)) + return (__vcpu_sys_reg(vcpu, SCTLR_EL2) & cache_bits) == cache_bits; + else + return (vcpu_read_sys_reg(vcpu, SCTLR_EL1) & cache_bits) == cache_bits; } Regardless, it is correct to use vcpu_read_sys_reg() for the SCTLR_EL1 case, as the most recent register value could be on the CPU in the VHE case, instead of being in memory, like it's always the case with the SCTLR_EL2 register: Reviewed-by: Alexandru Elisei Thanks, Alex > } > > static inline void __clean_dcache_guest_page(void *va, size_t size) > -- > 2.30.2 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel