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

[Marc Zyngier]

On Sun, 20 Sep 2026 10:15:25 +0100,
Yize Wang <wangyize7@xxxxxxxxxx> wrote:
> 
> 在 2026/9/18 20:08, Marc Zyngier 写道:
> > On Fri, 18 Sep 2026 09:18:13 +0100,
> > Yize Wang<wangyize7@xxxxxxxxxx> wrote:
> >> This series adds batch register access support to KVM/arm64 to reduce
> >> syscall overhead during VM live migration.
> >> 
> >> Currently, QEMU issues one ioctl per register when saving/restoring VGIC
> >> state. On large VM configurations this means tens of thousands of syscalls,
> >> where lock acquisition and context switch overhead dominates migration
> >> downtime. Thus, we provide a batch register method to allow userspace
> >> read/write multiple distributor and redistributor registers in a single call.
> >> In this way, we can significantly reduce syscalls and migration downtime.
> >> 
> >> Test the VM migration time under pressure conditions.
> >> The VM specifications for migration are as follows:
> >> - VM use 4-K page;
> >> - the number of VCPU is 160;
> >> - the total memory is 320Gigabit;
> >> - use 'Redis SET-benchmark' to pressurize VM;
> >> 
> >> Performance results (3-run average, ms):
> >>      | Metric              | Without patch | With patch | Improvement |
> >>      |---------------------|---------------|------------|-------------|
> >>      | Migration downtime  |        536    |     321    |     40%     |
> >>      | Source (total)      |        344    |     230    |     33%     |
> >>      |   - VGIC put        |        158    |      40    |     75%     |
> >>      |   - VGIC get        |        120    |      19    |     84%     |
> >>      | Destination (total) |        192    |      91    |     53%     |
> >>      |   - VGIC put        |        132    |      27    |     80%     |
> >> 
> >> Yize Wang (2):
> >>    KVM: arm64: Add batch group constant and data structure to UAPI header
> >>    KVM: arm64: Add VGIC v3 batch register access implementation
> > Questions:
> > 
> > - Why only the MMIO registers?
> > 
> > - Why not the sysregs?
> > 
> > - Why only the GIC?
> > 
> > - Why not all of the state?
> > 
> > - Where is the corresponding userspace code?
> > 
> > More importantly, since this is about batching system calls:
> > 
> > - Why can't this be done with io_uring instead?
> > 
> > 	M.
> 
> 
> Hi, Marc! Thank you for the review.
> 
>   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.

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