Re: [RFC] LoongArch: KVM: VCPU_EVENTS for pending interrupt/exception migration

Hi Tao,

On 2026/8/6 下午4:04, Tao Cui wrote:
> Hi Bibo,
> 
> I'd like to get your feedback on an approach for migrating the pending
> interrupt and exception state (irq_pending, irq_clear, exception_pending,
> esubcode) that is currently not captured by the CSR-based migration path.
> 
> I noticed your earlier work on this in the "Small enhancement about
> interrupt injection" series — specifically the kvm_vcpu_sync_intr() patch
> ([PATCH v3 6/6], 2026-05-19), which tried to fold irq_pending into the
> software ESTAT register before migration reads.  I see it was removed in
> v4 with the note that it "does not sync cached" state correctly, and the
> rest of the series was merged without it.
> 
> The core difficulty, as I understand it, is that irq_pending represents
> queued-but-not-yet-delivered interrupts, while ESTAT represents the
The main problem is that dmsintc is added recently, AI agent reports 
that interrupt status of dmsintc should be synced also, and synced to 
software state LOONGARCH_CSR_ISR0-LOONGARCH_CSR_ISR3 register from local 
state ds->vector_map[], similiar with function dmsintc_inject_irq().

If dmsintc is synced to software state, hardware registers about 
CSR_ISR0-CSR_ISR3 will be stale. And it need to restore from software 
status in _kvm_vcpu_load() even if KVM_LARCH_HWCSR_USABLE in 
vcpu->arch.aux_inuse is set.

That will be bigger change, and also AI agent reports variable vector[] 
is accessed without initialized issue. So this patch is removed :( 
However I think that vcpu_load()/vcpu_put() can be removed in 
_kvm_getcsr() at final.

> already-delivered state — folding the former into the latter would make
> the guest see interrupts it should not yet see.
> 
> My alternative approach is to add KVM_CAP_VCPU_EVENTS with a
> LoongArch-specific struct that captures these fields independently,
> without modifying ESTAT:
> 
>    struct kvm_vcpu_events {
>        __u64 irq_pending;
>        __u64 irq_clear;
>        __u64 exception_pending;
>        __u32 esubcode;
>        __u32 reserved[11];
>    };
Adding new uapi will lead to compatible issue. I think it is not necessary.

Regards
Bibo Mao
> 
> Userspace (QEMU) calls KVM_GET_VCPU_EVENTS during migration save and
> KVM_SET_VCPU_EVENTS during restore, keeping the queued/delivered
> distinction intact.  The kernel handler is straightforward — just
> read/write the four fields to/from vcpu->arch.
> 
> I've implemented both sides and verified end-to-end on a 3A6000:
> - Kernel: 3-file patch (uapi struct + cap advertisement + GET/SET
>    ioctl handlers), built on linux-next 20260805.
> - QEMU: 4-file patch (LA kvm header struct + CPUState fields +
>    VMState subsection + get/put in save/load path), built on
>    QEMU 11.1-rc3.
> - strace on a real source→dest migration confirms QEMU probes
>    KVM_CAP_VCPU_EVENTS (=1), then issues KVM_GET_VCPU_EVENTS on save
>    and KVM_SET_VCPU_EVENTS on restore for both vCPUs (all return 0).
> 
> Do you think this approach is reasonable?  I wanted to check with you
> before submitting, since you've worked in this area and might have
> insights on why the fold-into-ESTAT path was preferred (or if there
> are concerns with the separate-capture approach I'm missing).
> 
> Thanks,
> Tao
>