On Tue, Jun 14, 2022 at 4:11 AM Sasha Levin <sashal@xxxxxxxxxx> wrote: > > From: Paolo Bonzini <pbonzini@xxxxxxxxxx> > > [ Upstream commit 6cd88243c7e03845a450795e134b488fc2afb736 ] > > If a vCPU is outside guest mode and is scheduled out, it might be in the > process of making a memory access. A problem occurs if another vCPU uses > the PV TLB flush feature during the period when the vCPU is scheduled > out, and a virtual address has already been translated but has not yet > been accessed, because this is equivalent to using a stale TLB entry. > > To avoid this, only report a vCPU as preempted if sure that the guest > is at an instruction boundary. A rescheduling request will be delivered > to the host physical CPU as an external interrupt, so for simplicity > consider any vmexit *not* instruction boundary except for external > interrupts. > > It would in principle be okay to report the vCPU as preempted also > if it is sleeping in kvm_vcpu_block(): a TLB flush IPI will incur the > vmentry/vmexit overhead unnecessarily, and optimistic spinning is > also unlikely to succeed. However, leave it for later because right > now kvm_vcpu_check_block() is doing memory accesses. Even > though the TLB flush issue only applies to virtual memory address, > it's very much preferrable to be conservative. > > Reported-by: Jann Horn <jannh@xxxxxxxxxx> > Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> This feature was introduced in commit f38a7b75267f1f (first in 4.16). I think the fix has to be applied all the way back to there (so additionally to what you already did, it'd have to be added to 4.19, 5.4 and 5.10)? But it doesn't seem to apply cleanly to those older branches. Paolo, are you going to send stable backports of this?
