On Mon, Apr 13, 2020 at 05:09:45PM -0700, Jim Mattson wrote:
> Fixes: f4124500c2c13 ("KVM: nVMX: Fully emulate preemption timer")
> Signed-off-by: Jim Mattson <jmattson@xxxxxxxxxx>
> Reviewed-by: Oliver Upton <oupton@xxxxxxxxxx>
> Reviewed-by: Peter Shier <pshier@xxxxxxxxxx>
...
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 83050977490c..aae01253bfba 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -4682,7 +4682,7 @@ static int handle_exception_nmi(struct kvm_vcpu *vcpu)
> if (is_icebp(intr_info))
> WARN_ON(!skip_emulated_instruction(vcpu));
>
> - kvm_queue_exception(vcpu, DB_VECTOR);
> + kvm_requeue_exception(vcpu, DB_VECTOR);
This isn't wrong per se, but it's effectively papering over an underlying
bug, e.g. the same missed preemption timer bug can manifest if the timer
expires while in KVM context (because the hr timer is left running) and KVM
queues an exception for _any_ reason. Most of the scenarios where L0 will
queue an exception for L2 are fairly contrived, but they are possible.
I believe the correct fix is to open a "preemption timer window" like we do
for pending SMI, NMI and IRQ. It's effectively the same handling a pending
SMI on VMX, set req_immediate_exit in the !inject_pending_event() path.
Patches incoming soon-ish, think I've finally got my head wrapped around all
the combinations, though I also thought that was true several hours ago...
> return 1;
> }
> kvm_run->debug.arch.dr6 = dr6 | DR6_FIXED_1;
> @@ -4703,7 +4703,7 @@ static int handle_exception_nmi(struct kvm_vcpu *vcpu)
> break;
> case AC_VECTOR:
> if (guest_inject_ac(vcpu)) {
> - kvm_queue_exception_e(vcpu, AC_VECTOR, error_code);
> + kvm_requeue_exception_e(vcpu, AC_VECTOR, error_code);
> return 1;
> }
>
> --
> 2.26.0.110.g2183baf09c-goog
>
