Re: [PATCH v2] KVM: irqchip: KVM: Reduce allocation overhead in kvm_set_irq_routing()

[Sean Christopherson <seanjc@google.com>]

On Fri, Dec 26, 2025, Yanfei Xu wrote:
> In guests with many VFIO devices and MSI-X vectors, kvm_set_irq_routing()
> becomes a high-overhead operation. Each invocation walks the entire IRQ
> routing table and reallocates/frees every routing entry.
> 
> As the routing table grows on each call, entry allocation and freeing
> dominate the execution time of this function. In scenarios such as VM
> live migration or live upgrade, this behavior can introduce unnecessary
> downtime.
> 
> Allocate memory for all routing entries in one shot using kcalloc(),
> allowing them to be freed together with a single kfree() call.
> 
> Example: On a VM with 120 vCPUs and 15 VFIO devices (virtio-net), the
> total number of calls to kzalloc and kfree is over 20000. With this
> change, it is reduced to around 30.

...

> @@ -186,6 +175,12 @@ int kvm_set_irq_routing(struct kvm *kvm,
>  	new = kzalloc(struct_size(new, map, nr_rt_entries), GFP_KERNEL_ACCOUNT);
>  	if (!new)
>  		return -ENOMEM;
> +	e = kcalloc(nr, sizeof(*e), GFP_KERNEL_ACCOUNT);

This needs to be a kv flavor of allocation, or maybe even just a "straight to
vmalloc'd" allocation.  With 20000+ allocations, that means an order-BIG allocations.
So kvzalloc_obj() or kvmalloc_objs()?

And if we're going to allocate one massive array, then we definitely should get
rid of:

	/*
	 * Array indexed by gsi. Each entry contains list of irq chips
	 * the gsi is connected to.
	 */
	struct hlist_head map[];

and kvm_kernel_irq_routing_entry.list.  It'd be easier and faster to have
setup_routing_entry() simply iterate over the array.

Something we should look at (on top of this), is caching the previous routing
table.  I.e. instead of freeing the old table, keep it around, and try to reuse
the old table on the next update.  That would allow eliding the alloc+free
entirely when userspace is changing routing, but not adding or removing entries.