* [PATCH 2/2] KVM: selftests: Test arm64 stolen time after failed updates
2026-09-21 9:20 [PATCH 1/2] KVM: arm64: pvtime: Don't lose stolen time on failed updates Hao Zhang
@ 2026-09-21 9:27 ` Hao Zhang
2026-09-24 18:23 ` [PATCH 1/2] KVM: arm64: pvtime: Don't lose stolen time on " Marc Zyngier
1 sibling, 0 replies; 3+ messages in thread
From: Hao Zhang @ 2026-09-21 9:27 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, kvmarm, linux-arm-kernel,
linux-kernel
From: Hao Zhang <zhanghao1@kylinos.cn>
Use mprotect() to keep the stolen-time page readable while removing
write access. This allows kvm_get_guest() to succeed and forces the
subsequent kvm_put_guest() to fail.
Accumulate vCPU run delay, trigger the failed update, restore write
access, and run the vCPU again. Verify that the successful retry
includes the delay that could not be reported by the failed update.
Without the fix, KVM advances last_steal on the failed write and the
test observes that the accumulated delay is lost.
Signed-off-by: Hao Zhang <zhanghao1@kylinos.cn>
---
tools/testing/selftests/kvm/steal_time.c | 58 +++++++++++++++++++++++++++++++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/steal_time.c b/tools/testing/selftests/kvm/steal_time.c
index bc3c62b72c58..fbdd55fa5ab6 100644
--- a/tools/testing/selftests/kvm/steal_time.c
+++ b/tools/testing/selftests/kvm/steal_time.c
@@ -8,6 +8,8 @@
#include <time.h>
#include <sched.h>
#include <pthread.h>
+#include <sys/mman.h>
+#include <unistd.h>
#include <linux/kernel.h>
#include <asm/kvm.h>
#ifdef __riscv
@@ -162,6 +164,15 @@ static void guest_code(int cpu)
check_status(st);
WRITE_ONCE(guest_stolen_time[cpu], st->st_time);
+ if (!cpu) {
+ /*
+ * Let userspace trigger a failed stolen-time update, then retry
+ * the update after restoring write access.
+ */
+ GUEST_SYNC(2);
+ GUEST_SYNC(3);
+ WRITE_ONCE(guest_stolen_time[cpu], st->st_time);
+ }
GUEST_DONE();
}
@@ -469,9 +480,10 @@ static void check_steal_time_uapi(void)
static void *do_steal_time(void *arg)
{
struct timespec ts, stop;
+ unsigned long duration = arg ? *(unsigned long *)arg : MIN_RUN_DELAY_NS;
clock_gettime(CLOCK_MONOTONIC, &ts);
- stop = timespec_add_ns(ts, MIN_RUN_DELAY_NS);
+ stop = timespec_add_ns(ts, duration);
while (1) {
clock_gettime(CLOCK_MONOTONIC, &ts);
@@ -500,6 +512,45 @@ static void run_vcpu(struct kvm_vcpu *vcpu)
}
}
+#ifdef __aarch64__
+static void test_failed_stolen_time_update(struct kvm_vcpu *vcpu)
+{
+ struct kvm_vm *vm = vcpu->vm;
+ struct st_time *st = addr_gva2hva(vm, ST_GPA_BASE);
+ unsigned long duration = 100 * 1000 * 1000UL;
+ u64 stolen_time = st->st_time;
+ long run_delay;
+ pthread_t thread;
+
+ /*
+ * Keep the page readable so that kvm_get_guest() succeeds, but make
+ * kvm_put_guest() fail when KVM attempts to update stolen time.
+ */
+ TEST_ASSERT(!mprotect(st, getpagesize(), PROT_READ),
+ "Failed to make stolen time page read-only");
+
+ run_delay = get_run_delay();
+ kvm_pthread_create(&thread, NULL, do_steal_time, &duration);
+ do
+ sched_yield();
+ while (get_run_delay() - run_delay < duration / 5);
+ kvm_pthread_join(thread, NULL);
+ run_delay = get_run_delay() - run_delay;
+
+ /* The update fails, but the guest must still be able to run. */
+ run_vcpu(vcpu);
+ TEST_ASSERT(st->st_time == stolen_time,
+ "Stolen time changed on a read-only page");
+
+ TEST_ASSERT(!mprotect(st, getpagesize(), PROT_READ | PROT_WRITE),
+ "Failed to restore stolen time page write access");
+ run_vcpu(vcpu);
+ TEST_ASSERT(st->st_time - stolen_time >= run_delay,
+ "Lost stolen time after a failed update: expected >= %ld, got %lu",
+ run_delay, (unsigned long)(st->st_time - stolen_time));
+}
+#endif
+
int main(int ac, char **av)
{
struct kvm_vcpu *vcpus[NR_VCPUS];
@@ -569,6 +620,11 @@ int main(int ac, char **av)
"Expected stolen time >= %ld, got %ld",
run_delay, stolen_time);
+#ifdef __aarch64__
+ if (!i)
+ test_failed_stolen_time_update(vcpus[i]);
+#endif
+
if (verbose) {
ksft_print_msg("VCPU%d: total-stolen-time=%ld test-stolen-time=%ld%s\n",
i, guest_stolen_time[i], stolen_time,
--
2.15.0
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH 1/2] KVM: arm64: pvtime: Don't lose stolen time on failed updates
2026-09-21 9:20 [PATCH 1/2] KVM: arm64: pvtime: Don't lose stolen time on failed updates Hao Zhang
2026-09-21 9:27 ` [PATCH 2/2] KVM: selftests: Test arm64 stolen time after " Hao Zhang
@ 2026-09-24 18:23 ` Marc Zyngier
1 sibling, 0 replies; 3+ messages in thread
From: Marc Zyngier @ 2026-09-24 18:23 UTC (permalink / raw)
To: Hao Zhang
Cc: Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, kvmarm, linux-arm-kernel,
linux-kernel
On Mon, 21 Sep 2026 10:20:34 +0100,
Hao Zhang <hao_zhang_kdev@163.com> wrote:
>
> From: Hao Zhang <zhanghao1@kylinos.cn>
>
> kvm_update_stolen_time() advances last_steal before checking whether
> kvm_put_guest() successfully writes the updated value to guest memory.
>
> If the write fails, the updated stolen time is not visible to the guest,
> but the corresponding run delay has already been consumed from KVM's
> accounting state. A later successful update therefore starts from the
> advanced last_steal value and permanently loses that interval.
I'm sceptical.
A "transient" write failure means that userspace has unmapped the page
this should have been stored to. Userspace is in charge of the VM --
it literally is the owner.
Why should we prevent it from shooting itself in the foot? Userspace
can equally stop the vcpu from running, and this is "stolen time"
that is not accounted for.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply [flat|nested] 3+ messages in thread