1. 17 3月, 2020 34 次提交
  2. 23 2月, 2020 3 次提交
  3. 22 2月, 2020 3 次提交
    • V
      KVM: nVMX: clear PIN_BASED_POSTED_INTR from nested pinbased_ctls only when... · a4443267
      Vitaly Kuznetsov 提交于
      KVM: nVMX: clear PIN_BASED_POSTED_INTR from nested pinbased_ctls only when apicv is globally disabled
      
      When apicv is disabled on a vCPU (e.g. by enabling KVM_CAP_HYPERV_SYNIC*),
      nothing happens to VMX MSRs on the already existing vCPUs, however, all new
      ones are created with PIN_BASED_POSTED_INTR filtered out. This is very
      confusing and results in the following picture inside the guest:
      
      $ rdmsr -ax 0x48d
      ff00000016
      7f00000016
      7f00000016
      7f00000016
      
      This is observed with QEMU and 4-vCPU guest: QEMU creates vCPU0, does
      KVM_CAP_HYPERV_SYNIC2 and then creates the remaining three.
      
      L1 hypervisor may only check CPU0's controls to find out what features
      are available and it will be very confused later. Switch to setting
      PIN_BASED_POSTED_INTR control based on global 'enable_apicv' setting.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      a4443267
    • V
      KVM: nVMX: handle nested posted interrupts when apicv is disabled for L1 · 91a5f413
      Vitaly Kuznetsov 提交于
      Even when APICv is disabled for L1 it can (and, actually, is) still
      available for L2, this means we need to always call
      vmx_deliver_nested_posted_interrupt() when attempting an interrupt
      delivery.
      Suggested-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      91a5f413
    • W
      KVM: nVMX: Hold KVM's srcu lock when syncing vmcs12->shadow · c9dfd3fb
      wanpeng li 提交于
      For the duration of mapping eVMCS, it derefences ->memslots without holding
      ->srcu or ->slots_lock when accessing hv assist page. This patch fixes it by
      moving nested_sync_vmcs12_to_shadow to prepare_guest_switch, where the SRCU
      is already taken.
      
      It can be reproduced by running kvm's evmcs_test selftest.
      
        =============================
        warning: suspicious rcu usage
        5.6.0-rc1+ #53 tainted: g        w ioe
        -----------------------------
        ./include/linux/kvm_host.h:623 suspicious rcu_dereference_check() usage!
      
        other info that might help us debug this:
      
         rcu_scheduler_active = 2, debug_locks = 1
        1 lock held by evmcs_test/8507:
         #0: ffff9ddd156d00d0 (&vcpu->mutex){+.+.}, at:
      kvm_vcpu_ioctl+0x85/0x680 [kvm]
      
        stack backtrace:
        cpu: 6 pid: 8507 comm: evmcs_test tainted: g        w ioe     5.6.0-rc1+ #53
        hardware name: dell inc. optiplex 7040/0jctf8, bios 1.4.9 09/12/2016
        call trace:
         dump_stack+0x68/0x9b
         kvm_read_guest_cached+0x11d/0x150 [kvm]
         kvm_hv_get_assist_page+0x33/0x40 [kvm]
         nested_enlightened_vmentry+0x2c/0x60 [kvm_intel]
         nested_vmx_handle_enlightened_vmptrld.part.52+0x32/0x1c0 [kvm_intel]
         nested_sync_vmcs12_to_shadow+0x439/0x680 [kvm_intel]
         vmx_vcpu_run+0x67a/0xe60 [kvm_intel]
         vcpu_enter_guest+0x35e/0x1bc0 [kvm]
         kvm_arch_vcpu_ioctl_run+0x40b/0x670 [kvm]
         kvm_vcpu_ioctl+0x370/0x680 [kvm]
         ksys_ioctl+0x235/0x850
         __x64_sys_ioctl+0x16/0x20
         do_syscall_64+0x77/0x780
         entry_syscall_64_after_hwframe+0x49/0xbe
      Signed-off-by: NWanpeng Li <wanpengli@tencent.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      c9dfd3fb
反馈
建议
客服 返回
顶部