On Thu, Feb 26, 2026, Lance Yang wrote:
> On 2026/2/26 04:11, Sean Christopherson wrote:
> > On Mon, Feb 02, 2026, Lance Yang wrote:
> > > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> > > index 37dc8465e0f5..6a5e47ee4eb6 100644
> > > --- a/arch/x86/kernel/kvm.c
> > > +++ b/arch/x86/kernel/kvm.c
> > > @@ -856,6 +856,12 @@ static void __init kvm_guest_init(void)
> > > #ifdef CONFIG_SMP
> > > if (pv_tlb_flush_supported()) {
> > > pv_ops.mmu.flush_tlb_multi = kvm_flush_tlb_multi;
> > > + /*
> > > + * KVM's flush implementation calls native_flush_tlb_multi(),
> > > + * which sends real IPIs when INVLPGB is not available.
> >
> > Not on all (virtual) CPUs. The entire point of KVM's PV TLB flush is to
> > elide
> > the IPIs. If a vCPU was scheduled out by the host, the guest sets a flag
> > and
> > relies on the host to flush the TLB on behalf of the guest prior to the next
> > VM-Enter.
>
> Ah, I see. Thanks for the correction!
>
> KVM only sends IPIs to running vCPUs; preempted ones are left out of the mask
> and flushed on VM-Enter. So the old comment was wrong ...
>
> IIUC, we still set the flag to true because only running vCPUs can be in a
> software/lockless walk, and they all get the IPI, so the flush is enough.
>
> Does that match what you had in mind?
No, because from the guest kernel's perspective, the vCPU is running. The
kernel
can't make any assumptions about what code the vCPU was executing when the vCPU
was preempted by the host scheduler, i.e. it's entirely possible the vCPU is in
a software/lockless walk.
