1. 27 7月, 2008 3 次提交
  2. 20 7月, 2008 11 次提交
  3. 26 6月, 2008 2 次提交
  4. 24 6月, 2008 1 次提交
    • A
      KVM: VMX: Fix host msr corruption with preemption enabled · a9b21b62
      Avi Kivity 提交于
      Switching msrs can occur either synchronously as a result of calls to
      the msr management functions (usually in response to the guest touching
      virtualized msrs), or asynchronously when preempting a kvm thread that has
      guest state loaded.  If we're unlucky enough to have the two at the same
      time, host msrs are corrupted and the machine goes kaput on the next syscall.
      
      Most easily triggered by Windows Server 2008, as it does a lot of msr
      switching during bootup.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      a9b21b62
  5. 07 6月, 2008 2 次提交
  6. 04 5月, 2008 4 次提交
  7. 27 4月, 2008 14 次提交
  8. 25 3月, 2008 2 次提交
    • M
      KVM: VMX: convert init_rmode_tss() to slots_lock · 707a18a5
      Marcelo Tosatti 提交于
      init_rmode_tss was forgotten during the conversion from mmap_sem to
      slots_lock.
      
      INFO: task qemu-system-x86:3748 blocked for more than 120 seconds.
      Call Trace:
       [<ffffffff8053d100>] __down_read+0x86/0x9e
       [<ffffffff8053fb43>] do_page_fault+0x346/0x78e
       [<ffffffff8053d235>] trace_hardirqs_on_thunk+0x35/0x3a
       [<ffffffff8053dcad>] error_exit+0x0/0xa9
       [<ffffffff8035a7a7>] copy_user_generic_string+0x17/0x40
       [<ffffffff88099a8a>] :kvm:kvm_write_guest_page+0x3e/0x5f
       [<ffffffff880b661a>] :kvm_intel:init_rmode_tss+0xa7/0xf9
       [<ffffffff880b7d7e>] :kvm_intel:vmx_vcpu_reset+0x10/0x38a
       [<ffffffff8809b9a5>] :kvm:kvm_arch_vcpu_setup+0x20/0x53
       [<ffffffff8809a1e4>] :kvm:kvm_vm_ioctl+0xad/0x1cf
       [<ffffffff80249dea>] __lock_acquire+0x4f7/0xc28
       [<ffffffff8028fad9>] vfs_ioctl+0x21/0x6b
       [<ffffffff8028fd75>] do_vfs_ioctl+0x252/0x26b
       [<ffffffff8028fdca>] sys_ioctl+0x3c/0x5e
       [<ffffffff8020b01b>] system_call_after_swapgs+0x7b/0x80
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      707a18a5
    • A
      KVM: VMX: Restore tss even on x86_64 · 5dc83262
      Avi Kivity 提交于
      The vmx hardware state restore restores the tss selector and base address, but
      not its length.  Usually, this does not matter since most of the tss contents
      is within the default length of 0x67.  However, if a process is using ioperm()
      to grant itself I/O port permissions, an additional bitmap within the tss,
      but outside the default length is consulted.  The effect is that the process
      will receive a SIGSEGV instead of transparently accessing the port.
      
      Fix by restoring the tss length.  Note that i386 had this working already.
      
      Closes bugzilla 10246.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      5dc83262
  9. 04 3月, 2008 1 次提交
    • A
      KVM: VMX: Avoid rearranging switched guest msrs while they are loaded · 33f9c505
      Avi Kivity 提交于
      KVM tries to run as much as possible with the guest msrs loaded instead of
      host msrs, since switching msrs is very expensive.  It also tries to minimize
      the number of msrs switched according to the guest mode; for example,
      MSR_LSTAR is needed only by long mode guests.  This optimization is done by
      setup_msrs().
      
      However, we must not change which msrs are switched while we are running with
      guest msr state:
      
       - switch to guest msr state
       - call setup_msrs(), removing some msrs from the list
       - switch to host msr state, leaving a few guest msrs loaded
      
      An easy way to trigger this is to kexec an x86_64 linux guest.  Early during
      setup, the guest will switch EFER to not include SCE.  KVM will stop saving
      MSR_LSTAR, and on the next msr switch it will leave the guest LSTAR loaded.
      The next host syscall will end up in a random location in the kernel.
      
      Fix by reloading the host msrs before changing the msr list.
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      33f9c505