From: David Woodhouse <[email protected]> The final phase of xen_shinfo_test waits for a timer event while a worker thread repeatedly deactivates and reactivates the shared_info cache. The guest polls up to 100 times before asking the VMM to re-arm the timer, documenting the recovery protocol for kernels which drop a timer event that cannot be delivered.
But the poll has no timeout. If the timer fires while the guest is already blocked in SCHEDOP_poll and the event is dropped — which is precisely the case the recovery exists for — nothing ever wakes the vCPU, the 100-poll loop never advances, and the test hangs with the SIGALRM watchdog disabled for this phase. The recovery protocol is only reachable when the drop happens to occur while the guest is awake. Give the poll a 10ms timeout, as the TEST_POLL_TIMEOUT phase already does, so a dropped event leads to the documented re-arm protocol instead of sleeping forever. The window for the drop is vanishingly small upstream, but widens dramatically once cache deactivation incurs a grace-period wait, hanging roughly a third of all runs. Assisted-by: LLM Signed-off-by: David Woodhouse <[email protected]> --- tools/testing/selftests/kvm/x86/xen_shinfo_test.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/kvm/x86/xen_shinfo_test.c b/tools/testing/selftests/kvm/x86/xen_shinfo_test.c index 3b11d0ee253f..729c0ba9ab4e 100644 --- a/tools/testing/selftests/kvm/x86/xen_shinfo_test.c +++ b/tools/testing/selftests/kvm/x86/xen_shinfo_test.c @@ -350,7 +350,14 @@ static void guest_code(void) p = (struct sched_poll) { .ports = ports, .nr_ports = 1, - .timeout = 0 + /* + * The poll must have a timeout: if the timer event is dropped + * while we are already blocked in the poll, nothing else will + * ever wake us, and the recovery protocol below could never + * run. (As with TEST_POLL_TIMEOUT above, KVM treats the + * timeout as relative.) + */ + .timeout = 10000000, }; wait_for_timer: -- 2.43.0
