1. 28 8月, 2012 2 次提交
  2. 23 8月, 2012 1 次提交
    • A
      KVM: x86 emulator: use stack size attribute to mask rsp in stack ops · 5ad105e5
      Avi Kivity 提交于
      The sub-register used to access the stack (sp, esp, or rsp) is not
      determined by the address size attribute like other memory references,
      but by the stack segment's B bit (if not in x86_64 mode).
      
      Fix by using the existing stack_mask() to figure out the correct mask.
      
      This long-existing bug was exposed by a combination of a27685c3
      (emulate invalid guest state by default), which causes many more
      instructions to be emulated, and a seabios change (possibly a bug) which
      causes the high 16 bits of esp to become polluted across calls to real
      mode software interrupts.
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      5ad105e5
  3. 26 7月, 2012 2 次提交
  4. 21 7月, 2012 1 次提交
  5. 09 7月, 2012 16 次提交
  6. 14 5月, 2012 1 次提交
  7. 06 5月, 2012 2 次提交
  8. 24 4月, 2012 1 次提交
  9. 17 4月, 2012 5 次提交
  10. 08 3月, 2012 3 次提交
  11. 05 3月, 2012 3 次提交
  12. 01 2月, 2012 1 次提交
    • S
      KVM: x86: fix missing checks in syscall emulation · c2226fc9
      Stephan Bärwolf 提交于
      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: NStephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      c2226fc9
  13. 27 12月, 2011 2 次提交