1. 13 4月, 2017 10 次提交
  2. 07 4月, 2017 15 次提交
  3. 28 3月, 2017 2 次提交
  4. 24 3月, 2017 6 次提交
    • W
      KVM: VMX: Fix enable VPID conditions · 08d839c4
      Wanpeng Li 提交于
      This can be reproduced by running L2 on L1, and disable VPID on L0
      if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2
      crash as below:
      
      KVM: entry failed, hardware error 0x7
      EAX=00000000 EBX=00000000 ECX=00000000 EDX=000306c3
      ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
      EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
      ES =0000 00000000 0000ffff 00009300
      CS =f000 ffff0000 0000ffff 00009b00
      SS =0000 00000000 0000ffff 00009300
      DS =0000 00000000 0000ffff 00009300
      FS =0000 00000000 0000ffff 00009300
      GS =0000 00000000 0000ffff 00009300
      LDT=0000 00000000 0000ffff 00008200
      TR =0000 00000000 0000ffff 00008b00
      GDT=     00000000 0000ffff
      IDT=     00000000 0000ffff
      CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
      DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
      DR6=00000000ffff0ff0 DR7=0000000000000400
      EFER=0000000000000000
      
      Reference SDM 30.3 INVVPID:
      
      Protected Mode Exceptions
      - #UD
        - If not in VMX operation.
        - If the logical processor does not support VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=0).
        - If the logical processor supports VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=1) but does
          not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).
      
      So we should check both VPID enable bit in vmx exec control and INVVPID support bit
      in vmx capability MSRs to enable VPID. This patch adds the guarantee to not enable
      VPID if either INVVPID or single-context/all-context invalidation is not exposed in
      vmx capability MSRs.
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: NWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      08d839c4
    • W
      KVM: nVMX: Fix nested VPID vmx exec control · 63cb6d5f
      Wanpeng Li 提交于
      This can be reproduced by running kvm-unit-tests/vmx.flat on L0 w/ vpid disabled.
      
      Test suite: VPID
      Unhandled exception 6 #UD at ip 00000000004051a6
      error_code=0000      rflags=00010047      cs=00000008
      rax=0000000000000000 rcx=0000000000000001 rdx=0000000000000047 rbx=0000000000402f79
      rbp=0000000000456240 rsi=0000000000000001 rdi=0000000000000000
      r8=000000000000000a  r9=00000000000003f8 r10=0000000080010011 r11=0000000000000000
      r12=0000000000000003 r13=0000000000000708 r14=0000000000000000 r15=0000000000000000
      cr0=0000000080010031 cr2=0000000000000000 cr3=0000000007fff000 cr4=0000000000002020
      cr8=0000000000000000
      STACK: @4051a6 40523e 400f7f 402059 40028f
      
      We should hide and forbid VPID in L1 if it is disabled on L0. However, nested VPID
      enable bit is set unconditionally during setup nested vmx exec controls though VPID
      is not exposed through nested VMX capablity. This patch fixes it by don't set nested
      VPID enable bit if it is disabled on L0.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 5c614b35 (KVM: nVMX: nested VPID emulation)
      Signed-off-by: NWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      63cb6d5f
    • W
      KVM: x86: correct async page present tracepoint · 24dccf83
      Wanpeng Li 提交于
      After async pf setup successfully, there is a broadcast wakeup w/ special
      token 0xffffffff which tells vCPU that it should wake up all processes
      waiting for APFs though there is no real process waiting at the moment.
      
      The async page present tracepoint print prematurely and fails to catch the
      special token setup. This patch fixes it by moving the async page present
      tracepoint after the special token setup.
      
      Before patch:
      
      qemu-system-x86-8499  [006] ...1  5973.473292: kvm_async_pf_ready: token 0x0 gva 0x0
      
      After patch:
      
      qemu-system-x86-8499  [006] ...1  5973.473292: kvm_async_pf_ready: token 0xffffffff gva 0x0
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: NWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      24dccf83
    • J
      kvm: vmx: Flush TLB when the APIC-access address changes · fb6c8198
      Jim Mattson 提交于
      Quoting from the Intel SDM, volume 3, section 28.3.3.4: Guidelines for
      Use of the INVEPT Instruction:
      
      If EPT was in use on a logical processor at one time with EPTP X, it
      is recommended that software use the INVEPT instruction with the
      "single-context" INVEPT type and with EPTP X in the INVEPT descriptor
      before a VM entry on the same logical processor that enables EPT with
      EPTP X and either (a) the "virtualize APIC accesses" VM-execution
      control was changed from 0 to 1; or (b) the value of the APIC-access
      address was changed.
      
      In the nested case, the burden falls on L1, unless L0 enables EPT in
      vmcs02 when L1 doesn't enable EPT in vmcs12.
      Signed-off-by: NJim Mattson <jmattson@google.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      fb6c8198
    • P
      KVM: x86: use pic/ioapic destructor when destroy vm · c761159c
      Peter Xu 提交于
      We have specific destructors for pic/ioapic, we'd better use them when
      destroying the VM as well.
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      c761159c
    • P
      KVM: x86: check existance before destroy · 950712eb
      Peter Xu 提交于
      Mostly used for split irqchip mode. In that case, these two things are
      not inited at all, so no need to release.
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      950712eb
  5. 20 3月, 2017 3 次提交
  6. 17 3月, 2017 3 次提交
  7. 16 3月, 2017 1 次提交