1. 29 1月, 2015 2 次提交
  2. 26 1月, 2015 2 次提交
  3. 23 1月, 2015 1 次提交
  4. 21 1月, 2015 2 次提交
    • M
      KVM: x86: workaround SuSE's 2.6.16 pvclock vs masterclock issue · 54750f2c
      Marcelo Tosatti 提交于
      SuSE's 2.6.16 kernel fails to boot if the delta between tsc_timestamp
      and rdtsc is larger than a given threshold:
      
       * If we get more than the below threshold into the future, we rerequest
       * the real time from the host again which has only little offset then
       * that we need to adjust using the TSC.
       *
       * For now that threshold is 1/5th of a jiffie. That should be good
       * enough accuracy for completely broken systems, but also give us swing
       * to not call out to the host all the time.
       */
      #define PVCLOCK_DELTA_MAX ((1000000000ULL / HZ) / 5)
      
      Disable masterclock support (which increases said delta) in case the
      boot vcpu does not use MSR_KVM_SYSTEM_TIME_NEW.
      
      Upstreams kernels which support pvclock vsyscalls (and therefore make
      use of PVCLOCK_STABLE_BIT) use MSR_KVM_SYSTEM_TIME_NEW.
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      54750f2c
    • F
      KVM: fix "Should it be static?" warnings from sparse · 69b0049a
      Fengguang Wu 提交于
      arch/x86/kvm/x86.c:495:5: sparse: symbol 'kvm_read_nested_guest_page' was not declared. Should it be static?
      arch/x86/kvm/x86.c:646:5: sparse: symbol '__kvm_set_xcr' was not declared. Should it be static?
      arch/x86/kvm/x86.c:1183:15: sparse: symbol 'max_tsc_khz' was not declared. Should it be static?
      arch/x86/kvm/x86.c:1237:6: sparse: symbol 'kvm_track_tsc_matching' was not declared. Should it be static?
      Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      69b0049a
  5. 16 1月, 2015 1 次提交
  6. 09 1月, 2015 4 次提交
  7. 05 12月, 2014 1 次提交
  8. 24 11月, 2014 3 次提交
  9. 22 11月, 2014 1 次提交
  10. 13 11月, 2014 1 次提交
    • C
      kvm: svm: move WARN_ON in svm_adjust_tsc_offset · d913b904
      Chris J Arges 提交于
      When running the tsc_adjust kvm-unit-test on an AMD processor with the
      IA32_TSC_ADJUST feature enabled, the WARN_ON in svm_adjust_tsc_offset can be
      triggered. This WARN_ON checks for a negative adjustment in case __scale_tsc
      is called; however it may trigger unnecessary warnings.
      
      This patch moves the WARN_ON to trigger only if __scale_tsc will actually be
      called from svm_adjust_tsc_offset. In addition make adj in kvm_set_msr_common
      s64 since this can have signed values.
      Signed-off-by: NChris J Arges <chris.j.arges@canonical.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d913b904
  11. 10 11月, 2014 1 次提交
  12. 08 11月, 2014 3 次提交
  13. 07 11月, 2014 4 次提交
  14. 03 11月, 2014 3 次提交
  15. 24 10月, 2014 2 次提交
    • A
      KVM: x86: Prevent host from panicking on shared MSR writes. · 8b3c3104
      Andy Honig 提交于
      The previous patch blocked invalid writes directly when the MSR
      is written.  As a precaution, prevent future similar mistakes by
      gracefulling handle GPs caused by writes to shared MSRs.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NAndrew Honig <ahonig@google.com>
      [Remove parts obsoleted by Nadav's patch. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      8b3c3104
    • N
      KVM: x86: Check non-canonical addresses upon WRMSR · 854e8bb1
      Nadav Amit 提交于
      Upon WRMSR, the CPU should inject #GP if a non-canonical value (address) is
      written to certain MSRs. The behavior is "almost" identical for AMD and Intel
      (ignoring MSRs that are not implemented in either architecture since they would
      anyhow #GP). However, IA32_SYSENTER_ESP and IA32_SYSENTER_EIP cause #GP if
      non-canonical address is written on Intel but not on AMD (which ignores the top
      32-bits).
      
      Accordingly, this patch injects a #GP on the MSRs which behave identically on
      Intel and AMD.  To eliminate the differences between the architecutres, the
      value which is written to IA32_SYSENTER_ESP and IA32_SYSENTER_EIP is turned to
      canonical value before writing instead of injecting a #GP.
      
      Some references from Intel and AMD manuals:
      
      According to Intel SDM description of WRMSR instruction #GP is expected on
      WRMSR "If the source register contains a non-canonical address and ECX
      specifies one of the following MSRs: IA32_DS_AREA, IA32_FS_BASE, IA32_GS_BASE,
      IA32_KERNEL_GS_BASE, IA32_LSTAR, IA32_SYSENTER_EIP, IA32_SYSENTER_ESP."
      
      According to AMD manual instruction manual:
      LSTAR/CSTAR (SYSCALL): "The WRMSR instruction loads the target RIP into the
      LSTAR and CSTAR registers.  If an RIP written by WRMSR is not in canonical
      form, a general-protection exception (#GP) occurs."
      IA32_GS_BASE and IA32_FS_BASE (WRFSBASE/WRGSBASE): "The address written to the
      base field must be in canonical form or a #GP fault will occur."
      IA32_KERNEL_GS_BASE (SWAPGS): "The address stored in the KernelGSbase MSR must
      be in canonical form."
      
      This patch fixes CVE-2014-3610.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NNadav Amit <namit@cs.technion.ac.il>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      854e8bb1
  16. 03 10月, 2014 1 次提交
    • P
      kvm: do not handle APIC access page if in-kernel irqchip is not in use · f439ed27
      Paolo Bonzini 提交于
      This fixes the following OOPS:
      
         loaded kvm module (v3.17-rc1-168-gcec26bc3)
         BUG: unable to handle kernel paging request at fffffffffffffffe
         IP: [<ffffffff81168449>] put_page+0x9/0x30
         PGD 1e15067 PUD 1e17067 PMD 0
         Oops: 0000 [#1] PREEMPT SMP
          [<ffffffffa063271d>] ? kvm_vcpu_reload_apic_access_page+0x5d/0x70 [kvm]
          [<ffffffffa013b6db>] vmx_vcpu_reset+0x21b/0x470 [kvm_intel]
          [<ffffffffa0658816>] ? kvm_pmu_reset+0x76/0xb0 [kvm]
          [<ffffffffa064032a>] kvm_vcpu_reset+0x15a/0x1b0 [kvm]
          [<ffffffffa06403ac>] kvm_arch_vcpu_setup+0x2c/0x50 [kvm]
          [<ffffffffa062e540>] kvm_vm_ioctl+0x200/0x780 [kvm]
          [<ffffffff81212170>] do_vfs_ioctl+0x2d0/0x4b0
          [<ffffffff8108bd99>] ? __mmdrop+0x69/0xb0
          [<ffffffff812123d1>] SyS_ioctl+0x81/0xa0
          [<ffffffff8112a6f6>] ? __audit_syscall_exit+0x1f6/0x2a0
          [<ffffffff817229e9>] system_call_fastpath+0x16/0x1b
         Code: c6 78 ce a3 81 4c 89 e7 e8 d9 80 ff ff 0f 0b 4c 89 e7 e8 8f f6 ff ff e9 fa fe ff ff 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 <48> f7 07 00 c0 00 00 55 48 89 e5 75 1e 8b 47 1c 85 c0 74 27 f0
         RIP  [<ffffffff81193045>] put_page+0x5/0x50
      
      when not using the in-kernel irqchip ("-machine kernel_irqchip=off"
      with QEMU).  The fix is to make the same check in
      kvm_vcpu_reload_apic_access_page that we already have
      in vmx.c's vm_need_virtualize_apic_accesses().
      Reported-by: NJan Kiszka <jan.kiszka@siemens.com>
      Tested-by: NJan Kiszka <jan.kiszka@siemens.com>
      Fixes: 4256f43fSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      f439ed27
  17. 24 9月, 2014 8 次提交