On 14.08.25 23:04, Jason Andryuk wrote:
On 2025-08-14 03:05, Jürgen Groß wrote:
On 13.08.25 17:03, Jason Andryuk wrote:
On 2025-08-12 15:00, Jason Andryuk wrote:
VIRQs come in 3 flavors, per-VPU, per-domain, and global. The existing tracking of VIRQs is handled by per-cpu variables virq_to_irq.
The issue is that bind_virq_to_irq() sets the per_cpu virq_to_irq at registration time - typically CPU 0. Later, the interrupt can migrate, and info->cpu is updated. When calling unbind_from_irq(), the per-cpu virq_to_irq is cleared for a different cpu. If bind_virq_to_irq() is
This is what needs to be fixed. At migration the per_cpu virq_to_irq of the source and the target cpu need to be updated to reflect that migration.
I considered this, and even implemented it, before changing my approach. My concern was that the single VIRQ is now in one of the N per_cpu virq_to_irq arrays. A second attempt to register on CPU 0 will probably find -1 and continue and issue the hypercall.
The hypervisor would reject the attempt, right? So in the end no problem.
It looks like Xen tracks virq on the bind_virq vcpu, so per-domain/global stays on vcpu0. Binding again would return -EEXISTS. find_virq() would not match the virq if it was re-bound to a different vcpu.
We probably would want to modify find_virq() and bind_virq_to_irq() to not result in a BUG() if a non-percpu virq is bound to another cpu. This could be done by passing the percpu flag to find_virq() and let find_virq() return e.g. -EEXIST if a non-percpu virq is found to be bound to another cpu.
Juergen