An error occurred fetching the project authors.
  1. 30 May, 2018 2 commits
  2. 22 May, 2018 7 commits
  3. 26 Apr, 2018 1 commit
  4. 28 Mar, 2018 1 commit
    • Linus Torvalds's avatar
      kvm/x86: fix icebp instruction handling · 06b28101
      Linus Torvalds authored
      commit 32d43cd3 upstream.
      
      The undocumented 'icebp' instruction (aka 'int1') works pretty much like
      'int3' in the absense of in-circuit probing equipment (except,
      obviously, that it raises #DB instead of raising #BP), and is used by
      some validation test-suites as such.
      
      But Andy Lutomirski noticed that his test suite acted differently in kvm
      than on bare hardware.
      
      The reason is that kvm used an inexact test for the icebp instruction:
      it just assumed that an all-zero VM exit qualification value meant that
      the VM exit was due to icebp.
      
      That is not unlike the guess that do_debug() does for the actual
      exception handling case, but it's purely a heuristic, not an absolute
      rule.  do_debug() does it because it wants to ascribe _some_ reasons to
      the #DB that happened, and an empty %dr6 value means that 'icebp' is the
      most likely casue and we have no better information.
      
      But kvm can just do it right, because unlike the do_debug() case, kvm
      actually sees the real reason for the #DB in the VM-exit interruption
      information field.
      
      So instead of relying on an inexact heuristic, just use the actual VM
      exit information that says "it was 'icebp'".
      
      Right now the 'icebp' instruction isn't technically documented by Intel,
      but that will hopefully change.  The special "privileged software
      exception" information _is_ actually mentioned in the Intel SDM, even
      though the cause of it isn't enumerated.
      Reported-by: default avatarAndy Lutomirski <luto@kernel.org>
      Tested-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      06b28101
  5. 09 Mar, 2018 2 commits
  6. 25 Feb, 2018 1 commit
  7. 22 Feb, 2018 2 commits
  8. 16 Feb, 2018 2 commits
    • Liran Alon's avatar
      KVM: nVMX: Fix bug of injecting L2 exception into L1 · fe90a3a6
      Liran Alon authored
      commit 5c7d4f9a upstream.
      
      kvm_clear_exception_queue() should clear pending exception.
      This also includes exceptions which were only marked pending but not
      yet injected. This is because exception.pending is used for both L1
      and L2 to determine if an exception should be raised to guest.
      Note that an exception which is pending but not yet injected will
      be raised again once the guest will be resumed.
      
      Consider the following scenario:
      1) L0 KVM with ignore_msrs=false.
      2) L1 prepare vmcs12 with the following:
          a) No intercepts on MSR (MSR_BITMAP exist and is filled with 0).
          b) No intercept for #GP.
          c) vmx-preemption-timer is configured.
      3) L1 enters into L2.
      4) L2 reads an unhandled MSR that exists in MSR_BITMAP
      (such as 0x1fff).
      
      L2 RDMSR could be handled as described below:
      1) L2 exits to L0 on RDMSR and calls handle_rdmsr().
      2) handle_rdmsr() calls kvm_inject_gp() which sets
      KVM_REQ_EVENT, exception.pending=true and exception.injected=false.
      3) vcpu_enter_guest() consumes KVM_REQ_EVENT and calls
      inject_pending_event() which calls vmx_check_nested_events()
      which sees that exception.pending=true but
      nested_vmx_check_exception() returns 0 and therefore does nothing at
      this point. However let's assume it later sees vmx-preemption-timer
      expired and therefore exits from L2 to L1 by calling
      nested_vmx_vmexit().
      4) nested_vmx_vmexit() calls prepare_vmcs12()
      which calls vmcs12_save_pending_event() but it does nothing as
      exception.injected is false. Also prepare_vmcs12() calls
      kvm_clear_exception_queue() which does nothing as
      exception.injected is already false.
      5) We now return from vmx_check_nested_events() with 0 while still
      having exception.pending=true!
      6) Therefore inject_pending_event() continues
      and we inject L2 exception to L1!...
      
      This commit will fix above issue by changing step (4) to
      clear exception.pending in kvm_clear_exception_queue().
      
      Fixes: 664f8e26 ("KVM: X86: Fix loss of exception which has not yet been injected")
      Signed-off-by: default avatarLiran Alon <liran.alon@oracle.com>
      Reviewed-by: default avatarNikita Leshenko <nikita.leshchenko@oracle.com>
      Reviewed-by: default avatarKrish Sadhukhan <krish.sadhukhan@oracle.com>
      Signed-off-by: default avatarKrish Sadhukhan <krish.sadhukhan@oracle.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fe90a3a6
    • Liran Alon's avatar
      KVM: nVMX: Fix races when sending nested PI while dest enters/leaves L2 · 6bad5116
      Liran Alon authored
      commit 6b697711 upstream.
      
      Consider the following scenario:
      1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI
      to CPU B via virtual posted-interrupt mechanism.
      2. CPU B is currently executing L2 guest.
      3. vmx_deliver_nested_posted_interrupt() calls
      kvm_vcpu_trigger_posted_interrupt() which will note that
      vcpu->mode == IN_GUEST_MODE.
      4. Assume that before CPU A sends the physical POSTED_INTR_NESTED_VECTOR
      IPI, CPU B exits from L2 to L0 during event-delivery
      (valid IDT-vectoring-info).
      5. CPU A now sends the physical IPI. The IPI is received in host and
      it's handler (smp_kvm_posted_intr_nested_ipi()) does nothing.
      6. Assume that before CPU A sets pi_pending=true and KVM_REQ_EVENT,
      CPU B continues to run in L0 and reach vcpu_enter_guest(). As
      KVM_REQ_EVENT is not set yet, vcpu_enter_guest() will continue and resume
      L2 guest.
      7. At this point, CPU A sets pi_pending=true and KVM_REQ_EVENT but
      it's too late! CPU B already entered L2 and KVM_REQ_EVENT will only be
      consumed at next L2 entry!
      
      Another scenario to consider:
      1. CPU A calls vmx_deliver_nested_posted_interrupt() to send an IPI
      to CPU B via virtual posted-interrupt mechanism.
      2. Assume that before CPU A calls kvm_vcpu_trigger_posted_interrupt(),
      CPU B is at L0 and is about to resume into L2. Further assume that it is
      in vcpu_enter_guest() after check for KVM_REQ_EVENT.
      3. At this point, CPU A calls kvm_vcpu_trigger_posted_interrupt() which
      will note that vcpu->mode != IN_GUEST_MODE. Therefore, do nothing and
      return false. Then, will set pi_pending=true and KVM_REQ_EVENT.
      4. Now CPU B continue and resumes into L2 guest without processing
      the posted-interrupt until next L2 entry!
      
      To fix both issues, we just need to change
      vmx_deliver_nested_posted_interrupt() to set pi_pending=true and
      KVM_REQ_EVENT before calling kvm_vcpu_trigger_posted_interrupt().
      
      It will fix the first scenario by chaging step (6) to note that
      KVM_REQ_EVENT and pi_pending=true and therefore process
      nested posted-interrupt.
      
      It will fix the second scenario by two possible ways:
      1. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B has changed
      vcpu->mode to IN_GUEST_MODE, physical IPI will be sent and will be received
      when CPU resumes into L2.
      2. If kvm_vcpu_trigger_posted_interrupt() is called while CPU B hasn't yet
      changed vcpu->mode to IN_GUEST_MODE, then after CPU B will change
      vcpu->mode it will call kvm_request_pending() which will return true and
      therefore force another round of vcpu_enter_guest() which will note that
      KVM_REQ_EVENT and pi_pending=true and therefore process nested
      posted-interrupt.
      
      Fixes: 705699a1 ("KVM: nVMX: Enable nested posted interrupt processing")
      Signed-off-by: default avatarLiran Alon <liran.alon@oracle.com>
      Reviewed-by: default avatarNikita Leshenko <nikita.leshchenko@oracle.com>
      Reviewed-by: default avatarKrish Sadhukhan <krish.sadhukhan@oracle.com>
      [Add kvm_vcpu_kick to also handle the case where L1 doesn't intercept L2 HLT
       and L2 executes HLT instruction. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bad5116
  9. 07 Feb, 2018 8 commits
  10. 03 Feb, 2018 6 commits
  11. 17 Jan, 2018 3 commits
  12. 25 Dec, 2017 2 commits
  13. 20 Dec, 2017 1 commit
  14. 14 Dec, 2017 1 commit
  15. 05 Dec, 2017 1 commit