From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 E853637C11B; Fri, 15 May 2026 08:27:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778833645; cv=none; b=Yv5yu6gSTY4tGzRlhMM3f2ukRrrM4HjMQK1XA1YcsyJ/DGe3812NqqFyy0XWEOKrpqaJ0sed0GlqjiRp5hP3ggnbY9a+JNNtB4saPegKiJECmQ01Rq+ay5sR/m4LdDfQupENJinpsQrvz1rniwboIAO9SaJE6hqbWaWguq2vGy0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778833645; c=relaxed/simple; bh=HOXXqmybq5QwFKFflHP5my0ZlvqRbZxynm6vGw92Flg=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=jAYGBy407uA3sLYE95v6C7v9d7wCr2tTSdI33Ux6Da7NbdKW+EVYOoDuPNxt8ne4cpIcimG7YQpcZ6qfaX0QOl3SvhJtaM5d5CK6o10U3y/3k4IVW6YLoL/cGpMyuh0Dy/W6AaW/evTuec+NcdYtu+qQ+ufE22qgxu+PSXf6rZA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nyW1i8dO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nyW1i8dO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 77063C2BCB0; Fri, 15 May 2026 08:27:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778833644; bh=HOXXqmybq5QwFKFflHP5my0ZlvqRbZxynm6vGw92Flg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nyW1i8dOCbj19sa63ha/mgMMqwdQVUUZ6YC/Bos8/BC3h19ymefGl40v88CYtr6fy yU/2pp4iVilkcJSkPmn+pjhhwrFZrRtjrKllNFjHABgtUeGVUgGmOjGP4/mKCNwIkk UXsPB1Z7SHsiLYgTKbJKZkgcBevOS+W5ZTzD/ioqTaiPBgHEHvmyntplUPokCj4zev XSNqPNnpGEY/KphD90Teuh4wTEX03e/mcBFIoLJty+z/4sCaG9tnuYN5bAwwz2UO9O 1CViRgeljYOsoBLz9fj2OqtY+8UKxuhF+0q7YjR1SyjzBeILhmGyK6XirkEDTh4Mrh hjnWxpirYQvZA== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-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 1wNntC-00000002c3G-1OTt; Fri, 15 May 2026 08:27:22 +0000 Date: Fri, 15 May 2026 09:30:37 +0100 Message-ID: <87qznd9is2.wl-maz@kernel.org> From: Marc Zyngier To: sashiko-reviews@lists.linux.dev Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org, krzk+dt@kernel.org Subject: Re: [PATCH v2 03/17] clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE In-Reply-To: <20260514212312.BC29AC2BCB3@smtp.kernel.org> References: <20260514150945.3917510-4-maz@kernel.org> <20260514212312.BC29AC2BCB3@smtp.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: devicetree@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: sashiko-reviews@lists.linux.dev, conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org, krzk+dt@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 Thu, 14 May 2026 22:23:12 +0100, sashiko-bot@kernel.org wrote: > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > - [High] kvm_arch_ptp_get_crosststamp requests the physical counter from KVM when ARCH_TIMER_HYP_VIRT_PPI is used, conflicting with the virtual counter clocksource. > -- > > commit 46b3cf01730c13b97527ab1495a76cb40a0bdad8 > Author: Marc Zyngier > > clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE > > This commit switches the arch timer code to default to the virtual timer > when running in VHE mode. It ensures that the system clocksource utilizes > the virtual counter by treating ARCH_TIMER_HYP_VIRT_PPI similarly to > ARCH_TIMER_VIRT_PPI. > > > diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c > > index 90aeff44a2764..e3eb527650ec7 100644 > > --- a/drivers/clocksource/arm_arch_timer.c > > +++ b/drivers/clocksource/arm_arch_timer.c > > [ ... ] > > > @@ -912,7 +913,8 @@ static void __init arch_counter_register(void) > > int width; > > > > if ((IS_ENABLED(CONFIG_ARM64) && !is_hyp_mode_available()) || > > - arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI) { > > + arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI || > > + arch_timer_uses_ppi == ARCH_TIMER_HYP_VIRT_PPI) { > > if (arch_timer_counter_has_wa()) { > > rd = arch_counter_get_cntvct_stable; > > scr = raw_counter_get_cntvct_stable; > > Could this cause a mismatch in kvm_arch_ptp_get_crosststamp() where it still > only checks for ARCH_TIMER_VIRT_PPI? > > When ARCH_TIMER_HYP_VIRT_PPI is selected, the clocksource is backed by the > virtual counter here, but kvm_arch_ptp_get_crosststamp() will fall through > to the else branch and request KVM_PTP_PHYS_COUNTER from KVM: > > drivers/clocksource/arm_arch_timer.c:kvm_arch_ptp_get_crosststamp() { > ... > if (arch_timer_uses_ppi == ARCH_TIMER_VIRT_PPI) > ptp_counter = KVM_PTP_VIRT_COUNTER; > else > ptp_counter = KVM_PTP_PHYS_COUNTER; > ... > } > > When running as an L1 guest hypervisor in VHE mode, could this pair the > guest's virtual clocksource with the host's returned physical counter > timestamp? A VHE guest always sees physical and virtual timer being equal. There should be no offset applied, as per the architecture. The only case where an offset can be applied is when TGE=0 and that FEAT_ECV_POFF is implemented and enabled. But that an offset applied by the guest itself, and not the host. > Since the host hypervisor (L0) can apply an offset to the virtual counter, > comparing the guest's virtual counter cycle with the host's physical counter > timestamp might result in an incorrect time offset and affect PTP clock > synchronization for nested VHE guests. If there was an offset applied to one counter but not the other, L0 would be completely buggy. The only benefit to following the PPI in the case of a VHE guest would be to avoid a trap. So this only affects performance, not correctness. M. -- Jazz isn't dead. It just smells funny.