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

在 2026/8/6 16:48, Bibo Mao 写道:
> 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.
Thanks for the explanation, the DMSINTC part makes sense now.
> 
>> 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.
> 
I'll drop the VCPU_EVENTS idea.

Since you're already working on this direction, I'll wait for your
patch.  Happy to help test locally once it's ready.

Thanks,
Tao
> 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
>>
>