summaryrefslogtreecommitdiffstats
path: root/arch/h8300/lib/mulsi3.S
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2022-06-07 10:09:03 -0400
committerPaolo Bonzini <pbonzini@redhat.com>2022-06-08 04:21:07 -0400
commit6cd88243c7e03845a450795e134b488fc2afb736 (patch)
tree25f07d63e787b66a580809607269f592b90aec3e /arch/h8300/lib/mulsi3.S
parent54aa83c90198e68eee8b0850c749bc70efb548da (diff)
downloadlinux-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