Re: [PATCH 5.10 1/1] KVM: x86: do not report a vCPU as preempted outside instruction boundaries

[Greg KH <greg@kroah.com>]

On Tue, May 09, 2023 at 04:33:30PM +0300, ovidiu.panait@windriver.com wrote:
> From: Paolo Bonzini <pbonzini@redhat.com>
> 
> commit 6cd88243c7e03845a450795e134b488fc2afb736 upstream.
> 
> 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@google.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> [OP: use VCPU_STAT() for debugfs entries]
> Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
> ---
> 5.10 backport of CVE-2022-39189 fix:
> https://bugs.chromium.org/p/project-zero/issues/detail?id=2309
> 

Now queued up, thanks.

greg k-h