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() isThis 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
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
