Re: [PATCH] KVM: x86/xen: Fix sleeping lock in hard IRQ context on PREEMPT_RT

Woodhouse, David
2026-03-30T14:51:42Z

[-- Attachment #1.1: Type: text/plain, Size: 1467 bytes --]

On Mon, 2026-03-30 at 10:18 -0400, Steven Rostedt wrote:
>
> > +static void xen_timer_inject_irqwork(struct irq_work *work)
> > +{
> > +     struct kvm_vcpu_xen *xen = container_of(work, struct kvm_vcpu_xen,
> > +                                             timer_inject_irqwork);
> > +     struct kvm_vcpu *vcpu = container_of(xen, struct kvm_vcpu, arch.xen);
> > +     struct kvm_xen_evtchn e;
> > +     int rc;
> > +
> > +     e.vcpu_id = vcpu->vcpu_id;
> > +     e.vcpu_idx = vcpu->vcpu_idx;
> > +     e.port = vcpu->arch.xen.timer_virq;
> > +     e.priority = KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL;
> > +
> > +     rc = kvm_xen_set_evtchn_fast(&e, vcpu->kvm);
> > +     if (rc != -EWOULDBLOCK)
> > +             vcpu->arch.xen.timer_expires = 0;
> > +}
>
> Why duplicate this code and not simply make a static inline helper
> function that is used in both places?

It's already duplicating the functionality; the original
xen_timer_callback() will already fall back to injecting the IRQ in
process context when it needs to (by setting vcpu-
>arch.xen.timer_pending and then setting KVM_REQ_UNBLOCK).

All you had to do was make kvm_xen_set_evtchn_fast() return
-EWOULDBLOCK in the in_hardirq() case in order to use the existing
fallback, surely?

Better still, can't kvm_xen_set_evtchn_fast() just use read_trylock()
instead?

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5964 bytes --]

[-- Attachment #2.1: Type: text/plain, Size: 215 bytes --]

Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.

[-- Attachment #2.2: Type: text/html, Size: 228 bytes --]