1. 20 7月, 2008 11 次提交
  2. 26 6月, 2008 2 次提交
  3. 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
  4. 07 6月, 2008 2 次提交
  5. 04 5月, 2008 4 次提交
  6. 27 4月, 2008 14 次提交
  7. 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
  8. 04 3月, 2008 3 次提交
  9. 31 1月, 2008 1 次提交
    • S
      KVM: x86 emulator: Only allow VMCALL/VMMCALL trapped by #UD · 571008da
      Sheng Yang 提交于
      When executing a test program called "crashme", we found the KVM guest cannot
      survive more than ten seconds, then encounterd kernel panic. The basic concept
      of "crashme" is generating random assembly code and trying to execute it.
      
      After some fixes on emulator insn validity judgment, we found it's hard to
      get the current emulator handle the invalid instructions correctly, for the
      #UD trap for hypercall patching caused troubles. The problem is, if the opcode
      itself was OK, but combination of opcode and modrm_reg was invalid, and one
      operand of the opcode was memory (SrcMem or DstMem), the emulator will fetch
      the memory operand first rather than checking the validity, and may encounter
      an error there. For example, ".byte 0xfe, 0x34, 0xcd" has this problem.
      
      In the patch, we simply check that if the invalid opcode wasn't vmcall/vmmcall,
      then return from emulate_instruction() and inject a #UD to guest. With the
      patch, the guest had been running for more than 12 hours.
      Signed-off-by: NFeng (Eric) Liu <eric.e.liu@intel.com>
      Signed-off-by: NSheng Yang <sheng.yang@intel.com>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      571008da