Re: [PATCH 7/7] KVM: x86/xen: Handle pending Xen timer events in vcpu_enter_guest()

[David Woodhouse]

On Fri, 2026-05-08 at 19:10 +0100, David Woodhouse wrote:
> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> 
> If xen_timer_callback() can't deliver an event directly to the guest
> (e.g. due to memslot changes causing the GPC to need refreshing), it
> sets the timer_pending flag and kicks the vCPU.
> 
> However, the pending timer was only injected from the outer vcpu_run()
> loop via kvm_inject_pending_timer_irqs(), not from the inner loop in
> vcpu_enter_guest(). This means that the timer could be delayed until
> something else causes vcpu_enter_guest() to return to the outer loop.

This one is nonsense; I just got utterly confused when chasing the fact
that hrtimers weren't being delivered at all due to commit 15dd3a94885.

It's actually fine: the deferred timer will set KVM_REQ_UNBLOCK and
kvm_cpu_exit_request() will return true, causing vcpu_enter_guest() to
flip back to OUTSIDE_GUEST_MODE and bail early, as $DEITY intended.

After a two-day debugging session on the first thing, I came back to
the problem I *thought* I'd seen, and contrived a test which
demonstrated it... by introducing a race that didn't actually exist (my
test didn't set KVM_REQ_UNBLOCK when actually setting the timer flag in
vcpu_enter_guest() to show the race).

So we can drop this patch [7/7], but I might still do the cleanup and
consolidation of the events/timer part in a separate patch later.

Attachment: smime.p7s
Description: S/MIME cryptographic signature