Upon comparing with other places, it is possible to merely do isrc->xi_cpu = intr_next_cpu(0); here. At which point the section in xen_intr_bind_isrc() can do the xen_intr_assign_cpu() call.

newline, and cpu can likely be unsigned.

Why not make the call to intr_next_cpu here instead of stashing the value in xi_cpu and carrying it over from xen_intr_alloc_isrc?

<insert cursing at the stupid goof> Yeah, that should be.

If you look at diff #3, you'll see I was originally doing that. This approach though has two advantages:

1. This avoids the requirement to pass the event channel port to xen_intr_alloc_isrc()
2. This allows the cpu to be assigned here for all event channels, rather than doing assignments for VIRQ channels in xen_intr_bind_virq() and IPIs in xen_intr_bind_ipi() (see D32866).

Hmm, rereading I'm unsure I answered the right question. The previous is my reasoning for keeping the xen_intr_assign_cpu() call here, while moving the intr_next_cpu() call. The reason for moving the intr_next_cpu() call is in the main summary. Mainly intr_next_cpu() is x86-only. This isn't really an allocation task, but since xen_intr_alloc_isrc() is the portion being broken off, moving it there seems reasonable.

Could we maybe have something like xen_arch_intr_next_cpu() or similar, that is a per-arch function? On x86 it would be a wrapper around intr_next_cpu(), on Arm I'm not sure.

Certainly. The function for ARM is intr_irq_next_cpu() and matching the interface you're proposing would be simple to implement.

I dislike an entire extra function call into the architecture side merely for setting one variable. Particularly when xen_arch_intr_alloc() can readily handle this.

On the flip side, this would remove an access to a core variable by the architecture side.

Presently I still favor setting isrc->xi_cpu, but almost any interface is possible.

(see D31690 for the present ARM64 implementation)

If you have xen intr arch specific headers you could place this as a static inline function, in any case I'm not specially fuzzed by having an extra function call, at the end of day this is not a hot path. I think the extra call is worth having in order to avoid the dance with setting xi_cpu in one function just so that another one can figure out which CPU the interrupt should be bound to.

I'm not that bothered by the idea of having a xen_arch_intr_next_cpu() function. Including processor balancing as part of xen_arch_intr_alloc() though appears much more flexible. Requiring an extra function in a header means more maintenance than simply including it as part of setup.

It could be reasonable for an architecture to only set the vCPU on newly allocated sources, but leave it completely alone on reused sources. This would leave sources as balanced as they already are, as long as newly allocated sources are reasonably balanced. The interface you're proposing wouldn't allow this.