diff options
author | Paolo Bonzini <pbonzini@redhat.com> | 2022-06-07 10:09:03 -0400 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2022-06-08 04:21:07 -0400 |
commit | 6cd88243c7e03845a450795e134b488fc2afb736 (patch) | |
tree | 25f07d63e787b66a580809607269f592b90aec3e /arch/h8300/lib/mulsi3.S | |
parent | 54aa83c90198e68eee8b0850c749bc70efb548da (diff) | |
download | linux-6cd88243c7e03845a450795e134b488fc2afb736.tar.bz2 |
KVM: x86: do not report a vCPU as preempted outside instruction boundaries
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>
Diffstat (limited to 'arch/h8300/lib/mulsi3.S')
0 files changed, 0 insertions, 0 deletions