From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5BC745D5C7; Wed, 29 Jul 2026 10:58:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785322706; cv=none; b=eOLRDDe2pOEzGXeEihpAC7m+J/c0OdU3jQs/W66yQItkXx0ORkA1FBRPnPhaprui75trDLjSOSTvfm8X8HFTQQzijBx16TvRAbzolnceWy7/Vh1q81/M4FHeu60h+ntUEOSnOwbSRb9R0yCrhpbdZG+EcCimNB5501Vbrh4qoQM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785322706; c=relaxed/simple; bh=cA/TyjNainImWoZ1WgoIbtVzLcV/x03gUiUjuYc+ZpQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=R3LwA5kigFIweOwF+sNWzgN6eJS5UQGi7eW5dVKj6QyKm/2u0ZiajwmrCUjBZsvsJ6ypjEq5ddbjlupYC2z6a2VB72MJd6yPe07ea+sfmzU2gnZQ/7Be9GkjVZhdqySU5azmT49HvdFtxknmDsF97AEgwMZemeqC+l3QvPUGedE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eIXHdDcy; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eIXHdDcy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A42181F00A3A; Wed, 29 Jul 2026 10:58:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785322704; bh=VyFx2U/VszxvRM92qAy54Y4oL0XsKZy0mURmPScFf8w=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=eIXHdDcyltbN2unLeeeA8hK4cDT8x9vCiL57PIRrPd8uu0RllQdrFCsSPV9xq0JOz 2td1zXirKskj7jqLT9/fBwWgLbd0FrsgX120H9v5OdS4JJDGZmc4bFfpUgVWfrcw0j fa2k7XiTnH2vqPviyLvVAv8n9Wo1xlFJHxdVLNICu3jeIV8jOuN1kY0T+21mllbYuc kukncjy49nsuNQkxKeSsqYklKJ731WbThmJOBWxKh20tLBkr7NvhdclaFB8YH0WHwF 5HaZgBKQ4P5WgNGbk4ZRjrfM2y/EQcEraqYxDWPap85WhD0TVWsxMJ8oVBD+VHEVNe 8i4uxTOESTYWA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wp1zS-0000000A4TC-1yAO; Wed, 29 Jul 2026 10:58:22 +0000 Date: Wed, 29 Jul 2026 11:58:21 +0100 Message-ID: <86qzkmcbaq.wl-maz@kernel.org> From: Marc Zyngier To: Steven Price Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Will Deacon , James Morse , Oliver Upton , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" , Emi Kisanuki , Vishal Annapurve , WeiLin.Chang@arm.com, Lorenzo Pieralisi Subject: Re: [PATCH v15 13/37] KVM: arm64: CCA: Support timers in realm RECs In-Reply-To: References: <20260715142841.80544-1-steven.price@arm.com> <20260715142841.80544-14-steven.price@arm.com> <861pcoeqk5.wl-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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: steven.price@arm.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, oliver.upton@linux.dev, suzuki.poulose@arm.com, yuzenghui@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, joey.gouly@arm.com, alexandru.elisei@arm.com, christoffer.dall@arm.com, tabba@google.com, linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com, gshan@redhat.com, sdonthineni@nvidia.com, alpergun@google.com, aneesh.kumar@kernel.org, fj0570is@fujitsu.com, vannapurve@google.com, WeiLin.Chang@arm.com, lpieralisi@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 29 Jul 2026 11:47:03 +0100, Steven Price wrote: > > On 27/07/2026 10:21, Marc Zyngier wrote: > > On Wed, 15 Jul 2026 15:28:15 +0100, > > Steven Price wrote: > >> > >> The RMM keeps track of the timer while the realm REC is running, but on > >> exit to the normal world KVM is responsible for handling the timers. > >> > >> A later patch adds the support for propagating the timer values from the > >> exit data structure and calling kvm_realm_timers_update(). > >> > >> Signed-off-by: Steven Price > >> --- > >> Changes since v14: > >> * Special case in kvm_timer_vcpu_load()/kvm_timer_vcpu_put() the timer > >> handling. > >> Changes since v12: > >> * Adapt to upstream changes. > >> Changes since v11: > >> * Drop the kvm_is_realm() check from timer_set_offset(). We already > >> ensure that the offset is 0 when calling the function. > >> Changes since v10: > >> * KVM_CAP_COUNTER_OFFSET is now already hidden by a previous patch. > >> Changes since v9: > >> * No need to move the call to kvm_timer_unblocking() in > >> kvm_timer_vcpu_load(). > >> Changes since v7: > >> * Hide KVM_CAP_COUNTER_OFFSET for realm guests. > >> --- > >> arch/arm64/kvm/arch_timer.c | 38 +++++++++++++++++++++++++++++++++--- > >> include/kvm/arm_arch_timer.h | 2 ++ > >> 2 files changed, 37 insertions(+), 3 deletions(-) > >> > >> diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c > >> index 4155fe89b58a..fdd68f1f5b7b 100644 > >> --- a/arch/arm64/kvm/arch_timer.c > >> +++ b/arch/arm64/kvm/arch_timer.c > >> @@ -482,6 +482,20 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level, > >> timer_ctx); > >> } > >> > >> +void kvm_realm_timers_update(struct kvm_vcpu *vcpu) > >> +{ > >> + struct arch_timer_cpu *arch_timer = &vcpu->arch.timer_cpu; > >> + int i; > >> + > >> + for (i = 0; i < NR_KVM_EL0_TIMERS; i++) { > >> + struct arch_timer_context *timer = &arch_timer->timers[i]; > >> + bool status = timer_get_ctl(timer) & ARCH_TIMER_CTRL_IT_STAT; > >> + bool level = kvm_timer_enabled(timer) && status; > >> + > >> + kvm_timer_update_irq(vcpu, level, timer); > >> + } > >> +} > >> + > > > > Why do we need this? What is so special about CCA that it cannot use > > the existing timer flow? > > CCA is a little special because the timer context is owned by the RMM > while the realm is executing. It's the RMM which actually loads/saves > the timer registers not KVM. > > The RMM returns some of the timer state on every exit, and the host is > responsible for updating the interrupt status (as the host controls the > GIC emulation). But KVM relies on the timers being live when the vcpu is loaded. So the first port of call should be for CCA to adapt to KVM, and not the other way around. You can always make sure that the timers are in the registers at the point where you reach the KVM code. M. -- Without deviation from the norm, progress is not possible.