1. 01 Feb, 2012 4 commits
    • Gleb Natapov's avatar
      KVM: do not #GP on perf MSR writes when vPMU is disabled · 5753785f
      Gleb Natapov authored
      Return to behaviour perf MSR had before introducing vPMU in case vPMU
      is disabled. Some guests access those registers unconditionally and do
      not expect it to fail.
      Signed-off-by: default avatarGleb Natapov <gleb@redhat.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      5753785f
    • Stephan Bärwolf's avatar
      KVM: x86: fix missing checks in syscall emulation · c2226fc9
      Stephan Bärwolf authored
      On hosts without this patch, 32bit guests will crash (and 64bit guests
      may behave in a wrong way) for example by simply executing following
      nasm-demo-application:
      
          [bits 32]
          global _start
          SECTION .text
          _start: syscall
      
      (I tested it with winxp and linux - both always crashed)
      
          Disassembly of section .text:
      
          00000000 <_start>:
             0:   0f 05                   syscall
      
      The reason seems a missing "invalid opcode"-trap (int6) for the
      syscall opcode "0f05", which is not available on Intel CPUs
      within non-longmodes, as also on some AMD CPUs within legacy-mode.
      (depending on CPU vendor, MSR_EFER and cpuid)
      
      Because previous mentioned OSs may not engage corresponding
      syscall target-registers (STAR, LSTAR, CSTAR), they remain
      NULL and (non trapping) syscalls are leading to multiple
      faults and finally crashs.
      
      Depending on the architecture (AMD or Intel) pretended by
      guests, various checks according to vendor's documentation
      are implemented to overcome the current issue and behave
      like the CPUs physical counterparts.
      
      [mtosatti: cleanup/beautify code]
      Signed-off-by: default avatarStephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      c2226fc9
    • Stephan Bärwolf's avatar
      KVM: x86: extend "struct x86_emulate_ops" with "get_cpuid" · bdb42f5a
      Stephan Bärwolf authored
      In order to be able to proceed checks on CPU-specific properties
      within the emulator, function "get_cpuid" is introduced.
      With "get_cpuid" it is possible to virtually call the guests
      "cpuid"-opcode without changing the VM's context.
      
      [mtosatti: cleanup/beautify code]
      Signed-off-by: default avatarStephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      bdb42f5a
    • Takuya Yoshikawa's avatar
      KVM: Fix __set_bit() race in mark_page_dirty() during dirty logging · 50e92b3c
      Takuya Yoshikawa authored
      It is possible that the __set_bit() in mark_page_dirty() is called
      simultaneously on the same region of memory, which may result in only
      one bit being set, because some callers do not take mmu_lock before
      mark_page_dirty().
      
      This problem is hard to produce because when we reach mark_page_dirty()
      beginning from, e.g., tdp_page_fault(), mmu_lock is being held during
      __direct_map():  making kvm-unit-tests' dirty log api test write to two
      pages concurrently was not useful for this reason.
      
      So we have confirmed that there can actually be race condition by
      checking if some callers really reach there without holding mmu_lock
      using spin_is_locked():  probably they were from kvm_write_guest_page().
      
      To fix this race, this patch changes the bit operation to the atomic
      version:  note that nr_dirty_pages also suffers from the race but we do
      not need exactly correct numbers for now.
      Signed-off-by: default avatarTakuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      50e92b3c
  2. 25 Jan, 2012 4 commits
  3. 24 Jan, 2012 22 commits
  4. 23 Jan, 2012 10 commits