From: Fuad Tabba <fuad.tabba@linux.dev>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org,
qemu-stable@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Will Deacon" <will@kernel.org>, "Fuad Tabba" <tabba@google.com>
Subject: [PATCH 0/2] target/arm: Fix timer deadlines when the offset puts the count ahead
Date: Mon, 21 Sep 2026 08:44:49 +0100 [thread overview]
Message-ID: <20260921074451.3158645-1-fuad.tabba@linux.dev> (raw)
Hi folks,
Two fixes for the same bug in three places: the next-tick calculation
for the generic timers, WFIT and WFET each treat a 64-bit overflow of
cval + offset (or timeout + offset) as a deadline beyond the counter's
wrap. Once CNTVOFF_EL2 (or CNTPOFF_EL2 for the physical timer) puts
the timer's view of the counter ahead of the physical count, that sum
overflows for every deadline still in the future and QEMU arms the
timer at INT64_MAX. The first site regressed in 8.2 (8d37a1425b99).
The WFxT sites have the same overflow test.
The KVM arch_timer_edge_cases selftest, which sets the guest counter
to 2^59 - 1, hangs in every host mode on QEMU 11.0.0 and passes on
hardware under an nVHE host. With patch 1 it completes under nVHE and
pKVM hosts. Under a VHE host its physical-timer half still stops, on a
KVM bug in the same arithmetic (KVM programs cval + offset where the
timer compares unsigned). That fix goes to kvmarm separately.
Each patch adds a tcg system test that fails before it and passes
after.
Based on master (3b5d71cc36).
Cheers,
/fuad
Fuad Tabba (2):
target/arm: Fix next timer tick when the offset puts the count ahead
target/arm: Fix WFxT timeouts when the offset puts the count ahead
target/arm/helper.c | 9 +-
target/arm/tcg/op_helper.c | 6 +-
tests/tcg/aarch64/system/meson.build | 7 ++
tests/tcg/aarch64/system/vtimer.c | 28 +++++++
tests/tcg/aarch64/system/wfxt.c | 118 +++++++++++++++++++++++++++
5 files changed, 162 insertions(+), 6 deletions(-)
create mode 100644 tests/tcg/aarch64/system/wfxt.c
--
2.39.5
next reply other threads:[~2026-09-21 12:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 7:44 Fuad Tabba [this message]
2026-09-21 7:44 ` [PATCH 1/2] target/arm: Fix next timer tick when the offset puts the count ahead Fuad Tabba
2026-09-21 7:44 ` [PATCH 2/2] target/arm: Fix WFxT timeouts " Fuad Tabba
2026-09-30 8:56 ` Michael Tokarev
2026-09-30 11:41 ` Peter Maydell
2026-09-28 16:20 ` [PATCH 0/2] target/arm: Fix timer deadlines " Peter Maydell
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=20260921074451.3158645-1-fuad.tabba@linux.dev \
--to=fuad.tabba@linux.dev \
--cc=alex.bennee@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=tabba@google.com \
--cc=will@kernel.org \
/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.