Re: [PATCH v4 2/3] LoongArch: KVM: Implement guest-side PV TLB flush

[Tao Cui <cui.tao@linux.dev>]

Hi Bibo,

That's really kind of you. I'd really value the chance to work with you.

在 2026/6/16 09:14, Bibo Mao 写道:
> 
>> +            __cpumask_clear_cpu(cpu, flushmask);
> is it possible that vCPU is running however with KVM_VCPU_PREEMPTED set?

It shouldn't happen with a correct host: the bit is set on vcpu_put
(preempt) and cleared on entry through kvm_update_stolen_time(), so a
running vCPU always has preempted == 0. The guest-side race is closed by
try_cmpxchg(). If the host clears the byte between the guest's READ_ONCE
and the cmpxchg, the cmpxchg fails and the CPU stays in the IPI mask, so
no flush is missed. The only thing that can break the invariant is the
error path from patch 1, which the conservative handling there closes.
Point taken though: the design's correctness rests entirely on the host
honoring this, so I agree the patch-1 fix is necessary rather than
optional.

>> +    }
>> +
>> +    on_each_cpu_mask(flushmask, func, info, 1);
> LoongArch VM does not support post interrupt now, IPI with vCPU will trap to hypervisor.
> 
> There is another PV TLB flush method using hypercall like PV IPI, which will make a request with wait flag such as KVM_REQ_TLB_FLUSH and kick vCPU.
> 
> With this PV TLB flush method, there is not IPI interrupt in VM, and wait is handled in hypervisor, the negative effect is that it flushes all TLBs.
> 
This is the point I most want to get right, and you're correct. Since
LoongArch has no posted interrupts, an IPI to a *running* vCPU still
traps, so the steal-time path only genuinely helps for preempted/idle
vCPUs; for running ones it's no better (a little heavier) than a plain
IPI. The hypercall approach (analogous to our PV IPI) would avoid
in-guest IPIs entirely, at the cost of a full TLB flush and
hypervisor-side wait handling.

Rather than argue from intuition, I'd like to try the hypercall approach
you suggested and measure the performance improvement against the current
path. I'll share the results with you once the testing is done, so we
can decide the direction based on the numbers.

> FYI, another PV TLB flush method in arch/x86/hyperv/mmu.c ...

Thanks for the pointer. The Hyper-V path is a pure hypercall: the guest
hands the hypervisor the address space, an address-range list, and the
target VP set, so the flush stays fine-grained instead of nuking the
whole TLB. That's a good template if the numbers point us toward a
hypercall-based design.

Thanks,
Tao