Re: [PATCH v2 03/17] clocksource/drivers/arm_arch_timer: Default to EL2 virtual timer when running VHE

[sashiko-bot@kernel.org]

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 <maz@kernel.org>

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?

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.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514150945.3917510-1-maz@kernel.org?part=3