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 C0C7BD1AD39 for ; Wed, 16 Oct 2024 09:45: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:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=A0G9UDkxfhMnQnZUG2Pg4glDfB8cqRs7oHJTeIHWQX0=; b=V9nqRnfBX7G8FrHtedqTqL2Ogm EpAo0hnbmNVnOrqdR1Dy2gNiAtofGVmNMbw42E7rOgckWBtCZ0gZnDiMPxKNqifJ9/zC/llE3fOLN hON0JfZxh9mGpBEXLeN0MiKn2kjd3JLFrLGJU0leShM6e+NMPCRdKX4S6nE15ki8Y9KP1MpPZPwNo l9P2ZMDDFHXvPQJjYdZLa9XpnIRuZY9jWRoEzSMgChziophGg292y+/q4Rc4346rnHzV3Wsbeo2Vk W4W1U+6wD72daN9ZLbLNG0AP3Cu9kMTt4i9R+RHeSF9oGwCrJ2MLDTgWaxdBR5Z9WQEGfWRzd4JF+ 9aP6CZjg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t10af-0000000BHyY-00G9; Wed, 16 Oct 2024 09:45:13 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t10T8-0000000BG0d-0Jv1 for linux-arm-kernel@lists.infradead.org; Wed, 16 Oct 2024 09:37:28 +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 98778FEC; Wed, 16 Oct 2024 02:37:52 -0700 (PDT) Received: from raptor (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4338B3F528; Wed, 16 Oct 2024 02:37:21 -0700 (PDT) Date: Wed, 16 Oct 2024 10:37:18 +0100 From: Alexandru Elisei To: Marc Zyngier Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Mark Brown Subject: Re: [PATCH v4 06/36] KVM: arm64: nv: Handle CNTHCTL_EL2 specially Message-ID: References: <20241009190019.3222687-1-maz@kernel.org> <20241009190019.3222687-7-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241009190019.3222687-7-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241016_023726_227974_49EF396D X-CRM114-Status: GOOD ( 27.92 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Marc, I'm planning to have a look at (some) of the patches, do you have a timeline for merging the series? Just so I know what to prioritise. On Wed, Oct 09, 2024 at 07:59:49PM +0100, Marc Zyngier wrote: > Accessing CNTHCTL_EL2 is fraught with danger if running with > HCR_EL2.E2H=1: half of the bits are held in CNTKCTL_EL1, and > thus can be changed behind our back, while the rest lives > in the CNTHCTL_EL2 shadow copy that is memory-based. > > Yes, this is a lot of fun! > > Make sure that we merge the two on read access, while we can > write to CNTKCTL_EL1 in a more straightforward manner. > > Signed-off-by: Marc Zyngier > --- > arch/arm64/kvm/sys_regs.c | 28 ++++++++++++++++++++++++++++ > include/kvm/arm_arch_timer.h | 3 +++ > 2 files changed, 31 insertions(+) > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 3cd54656a8e2f..932d2fb7a52a0 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -157,6 +157,21 @@ u64 vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, int reg) > if (!is_hyp_ctxt(vcpu)) > goto memory_read; > > + /* > + * CNTHCTL_EL2 requires some special treatment to > + * account for the bits that can be set via CNTKCTL_EL1. > + */ > + switch (reg) { > + case CNTHCTL_EL2: > + if (vcpu_el2_e2h_is_set(vcpu)) { > + val = read_sysreg_el1(SYS_CNTKCTL); > + val &= CNTKCTL_VALID_BITS; > + val |= __vcpu_sys_reg(vcpu, reg) & ~CNTKCTL_VALID_BITS; > + return val; > + } > + break; > + } > + > /* > * If this register does not have an EL1 counterpart, > * then read the stored EL2 version. > @@ -207,6 +222,19 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, int reg) > */ > __vcpu_sys_reg(vcpu, reg) = val; > > + switch (reg) { > + case CNTHCTL_EL2: > + /* > + * If E2H=0, CNHTCTL_EL2 is a pure shadow register. > + * Otherwise, some of the bits are backed by > + * CNTKCTL_EL1, while the rest is kept in memory. > + * Yes, this is fun stuff. > + */ > + if (vcpu_el2_e2h_is_set(vcpu)) > + write_sysreg_el1(val, SYS_CNTKCTL); Sorry, but I just can't seem to get my head around why the RES0 bits aren't cleared. Is KVM relying on the guest to implement Should-Be-Zero-or-Preserved, as per the RES0 definition? > + return; > + } > + > /* No EL1 counterpart? We're done here.? */ > if (reg == el1r) > return; > diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h > index c819c5d16613b..fd650a8789b91 100644 > --- a/include/kvm/arm_arch_timer.h > +++ b/include/kvm/arm_arch_timer.h > @@ -147,6 +147,9 @@ u64 timer_get_cval(struct arch_timer_context *ctxt); > void kvm_timer_cpu_up(void); > void kvm_timer_cpu_down(void); > > +/* CNTKCTL_EL1 valid bits as of DDI0487J.a */ > +#define CNTKCTL_VALID_BITS (BIT(17) | GENMASK_ULL(9, 0)) This does match CNTHCTL_EL2_VHE(). Thanks, Alex > + > static inline bool has_cntpoff(void) > { > return (has_vhe() && cpus_have_final_cap(ARM64_HAS_ECV_CNTPOFF)); > -- > 2.39.2 >