From: sashiko-bot@kernel.org
To: "Fuad Tabba" <fuad.tabba@linux.dev>
Cc: "Oliver Upton" <oupton@kernel.org>,
"Marc Zyngier" <maz@kernel.org>,
kvm@vger.kernel.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH 3/3] KVM: arm64: selftests: Test a timer set past the counter's wrap
Date: Mon, 21 Sep 2026 14:17:00 +0000 [thread overview]
Message-ID: <20260921141701.33CFD1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260921140427.2211373-4-fuad.tabba@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selftests: flaky test due to scheduling delay in test_timers_past_counter_wrap
--
commit 8788b1ebd8d97a89915e8766ef7a7c75ad83b3c9
Author: Fuad Tabba <fuad.tabba@linux.dev>
KVM: arm64: selftests: Test a timer set past the counter's wrap
This commit adds a KVM selftest to verify timer behavior when programmed
with a cval past the counter's wrap point. It programs an unmasked timer
and tests that no unexpected interrupts fire since the guest's counter
cannot realistically reach the deadline.
> diff --git a/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c b/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
> index d9c9377a63256..69986a7f0d37d 100644
> --- a/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
> +++ b/tools/testing/selftests/kvm/arm64/arch_timer_edge_cases.c
[ ... ]
> +/*
> + * With the counter at wait_ms, a tval of -(wait_ms + long_wait_ms) puts cval
> + * within long_wait_ms of the counter's wrap: a deadline further away than the
> + * counter can reach. Unmasked, so an early ISTATUS shows up as an IRQ.
> + */
> +static void test_timers_past_counter_wrap(enum arch_timer timer)
> +{
> + s32 tval = -(s32)msec_to_cycles(test_args.wait_ms + test_args.long_wait_ms);
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(sleep_method); i++) {
> + sleep_method_t sm = sleep_method[i];
> +
> + local_irq_disable();
> + set_counter(timer, msec_to_cycles(test_args.wait_ms));
> + set_tval_irq(timer, tval, CTL_ENABLE);
[Severity: Medium]
Could this sequence lead to a flaky test on a loaded host system?
If a host scheduling delay exceeds long_wait_ms between setting the counter
and writing the TVAL, the guest's CNT can advance such that:
CNT > wait_ms + long_wait_ms
When set_tval_irq() then executes, the hardware calculates the absolute
deadline as CVAL = CNT + TVAL. Because TVAL is a negative value of
-(wait_ms + long_wait_ms), CVAL evaluates to a small positive number
instead of wrapping around to near U64_MAX.
Since CVAL is now less than CNT, the timer condition (CNT >= CVAL) is
met immediately, and the hardware legitimately fires the unmasked timer.
This would cause the subsequent assert_irqs_handled(0) check to fail.
> + sm(timer, msecs_to_usecs(test_args.wait_ms) + TIMEOUT_NO_IRQ_US);
> + local_irq_enable();
> + isb();
> + assert_irqs_handled(0);
> + timer_set_ctl(timer, CTL_IMASK);
> + }
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260921140427.2211373-1-fuad.tabba@linux.dev?part=3
next prev parent reply other threads:[~2026-09-21 14:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 14:04 [PATCH 0/3] KVM: arm64: timers: Program CVAL from the current count when the hardware won't apply the offset Fuad Tabba
2026-09-21 14:04 ` [PATCH 1/3] KVM: arm64: timers: Compute an offset-applied CVAL from the current count Fuad Tabba
2026-09-21 14:04 ` [PATCH 2/3] KVM: arm64: nv: Read a guest hypervisor's CNTV_CVAL_EL0 from memory on x1e Fuad Tabba
2026-09-21 14:04 ` [PATCH 3/3] KVM: arm64: selftests: Test a timer set past the counter's wrap Fuad Tabba
2026-09-21 14:17 ` sashiko-bot [this message]
2026-09-21 15:25 ` Fuad Tabba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260921141701.33CFD1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=fuad.tabba@linux.dev \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.