[RESEND][PATCH 0/2] Batch register access for live migration optimization

[Marc Zyngier]

On Thu, 08 Oct 2026 13:50:57 +0100,
Yize Wang <wangyize7 at huawei.com> wrote:
> 
> 
> 在 2026/10/3 22:53, Marc Zyngier 写道:
> > On Sun, 20 Sep 2026 10:15:25 +0100,
> > Yize Wang <wangyize7 at huawei.com> wrote:
> >> 在 2026/9/18 20:08, Marc Zyngier 写道:
> >>> On Fri, 18 Sep 2026 09:18:13 +0100,
> >>> Yize Wang<wangyize7 at huawei.com> wrote:
> >>    These patches focus on optimizing GICv3 register access during live
> >> migration. We found that there are a large number of locks (kvm->lock,
> >> vcpus, config_lock) in the GIC, these lock operations wil cost large
> >> time waste. The batches of sysreg for vcpu optimization will come in
> >> follow as a separate series. And let me address these questions one by
> >> one.
> > All these locks should be non-blocking by the time you save anything
> > related to the GIC, because:
> > 
> > - none of the vcpu can be running
> > 
> > - this must be a single threaded operation
> > 
> > So if you are seeing anything contended, this is either the sign of a
> > bad KVM bug, or an indication that you are violating the above
> > requirements.
> > 
> > 	M.
> 
> 
> Hi, Marc! Thanks for your review.
> 
> You are right that when saving the GIC state during live migration
> process, all vCPUs are not running and it is a single threaded
> operation. Our patches process the packaged register states from the
> userspace under the same lock. These operations only aim to reduce
> the lock opreation downtime and do not involve lock contention.

OK, so your argument was actively misleading, since you were claiming
that locks were the majority of the overhead, and are now
advocating... something else.

> In addition, these patches focus on reducing the syscalls of
> ioctl. Now, every register requires an ioctl, resulting in (num_cpu
> * registers_per_cpu) system calls. This will cost lots of time
> during the large-scale VM migration. Our patches batch registers by
> category in qemu and then send them to kernel in batches. This
> operations significantly reduce the number of ioctl syscalls and
> save a great amount of downtime.

I've suggested you use io_uring, and you completely disregarded my
suggestion based on... locking contention. How do you expect me to
take you seriously?

I've now marked this series as rejected. Please come back once you and
your AI toy have agreed on what you want to do.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.