1. 24 3月, 2009 2 次提交
    • J
      KVM: Remove old kvm_guest_debug structs · 989c0f0e
      Jan Kiszka 提交于
      Remove the remaining arch fragments of the old guest debug interface
      that now break non-x86 builds.
      Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      989c0f0e
    • J
      KVM: New guest debug interface · d0bfb940
      Jan Kiszka 提交于
      This rips out the support for KVM_DEBUG_GUEST and introduces a new IOCTL
      instead: KVM_SET_GUEST_DEBUG. The IOCTL payload consists of a generic
      part, controlling the "main switch" and the single-step feature. The
      arch specific part adds an x86 interface for intercepting both types of
      debug exceptions separately and re-injecting them when the host was not
      interested. Moveover, the foundation for guest debugging via debug
      registers is layed.
      
      To signal breakpoint events properly back to userland, an arch-specific
      data block is now returned along KVM_EXIT_DEBUG. For x86, the arch block
      contains the PC, the debug exception, and relevant debug registers to
      tell debug events properly apart.
      
      The availability of this new interface is signaled by
      KVM_CAP_SET_GUEST_DEBUG. Empty stubs for not yet supported archs are
      provided.
      
      Note that both SVM and VTX are supported, but only the latter was tested
      yet. Based on the experience with all those VTX corner case, I would be
      fairly surprised if SVM will work out of the box.
      Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      d0bfb940
  2. 18 3月, 2009 3 次提交
  3. 19 2月, 2009 2 次提交
  4. 11 2月, 2009 1 次提交
  5. 23 1月, 2009 1 次提交
  6. 15 1月, 2009 1 次提交
  7. 09 1月, 2009 5 次提交
  8. 07 1月, 2009 3 次提交
  9. 01 1月, 2009 1 次提交
  10. 31 12月, 2008 4 次提交
  11. 30 12月, 2008 1 次提交
  12. 26 12月, 2008 1 次提交
  13. 25 12月, 2008 13 次提交
  14. 01 12月, 2008 1 次提交
  15. 27 11月, 2008 1 次提交
    • C
      [S390] pgtable.h: Fix oops in unmap_vmas for KVM processes · 2944a5c9
      Christian Borntraeger 提交于
      When running several kvm processes with lots of memory overcommitment,
      we have seen an oops during process shutdown:
      ------------[ cut here ]------------
      Kernel BUG at 0000000000193434 [verbose debug info unavailable]
      addressing exception: 0005 [#1] PREEMPT SMP
      Modules linked in: kvm sunrpc qeth_l2 dm_mod qeth ccwgroup
      CPU: 10 Not tainted 2.6.28-rc4-kvm-bigiron-00521-g0ccca08-dirty #8
      Process kuli (pid: 14460, task: 0000000149822338, ksp: 0000000024f57650)
      Krnl PSW : 0704e00180000000 0000000000193434 (unmap_vmas+0x884/0xf10)
      R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 EA:3
      Krnl GPRS: 0000000000000002 0000000000000000 000000051008d000 000003e05e6034e0
                 00000000001933f6 00000000000001e9 0000000407259e0a 00000002be88c400
                 00000200001c1000 0000000407259608 0000000407259e08 0000000024f577f0
                 0000000407259e09 0000000000445fa8 00000000001933f6 0000000024f577f0
      Krnl Code: 0000000000193426: eb22000c000d sllg %r2,%r2,12
                 000000000019342c: a7180000 lhi %r1,0
                 0000000000193430: b2290012 iske %r1,%r2
                >0000000000193434: a7110002 tmll %r1,2
                 0000000000193438: a7840006 brc 8,193444
                 000000000019343c: 9602c000 oi 0(%r12),2
                 0000000000193440: 96806000 oi 0(%r6),128
                 0000000000193444: a7110004 tmll %r1,4
      Call Trace:
      ([<00000000001933f6>] unmap_vmas+0x846/0xf10)
      [<0000000000199680>] exit_mmap+0x210/0x458
      [<000000000012a8f8>] mmput+0x54/0xfc
      [<000000000012f714>] exit_mm+0x134/0x144
      [<000000000013120c>] do_exit+0x240/0x878
      [<00000000001318dc>] do_group_exit+0x98/0xc8
      [<000000000013e6b0>] get_signal_to_deliver+0x30c/0x358
      [<000000000010bee0>] do_signal+0xec/0x860
      [<0000000000112e30>] sysc_sigpending+0xe/0x22
      [<000002000013198a>] 0x2000013198a
      INFO: lockdep is turned off.
      Last Breaking-Event-Address:
      [<00000000001a68d0>] free_swap_and_cache+0x1a0/0x1a4
      <4>---[ end trace bc19f1d51ac9db7c ]---
      
      The faulting instruction is the storage key operation (iske) in
      ptep_rcp_copy (called by pte_clear, called by unmap_vmas). iske
      reads dirty and reference bit information for a physical page and
      requires a valid physical address. Since we are in pte_clear, we
      cannot rely on the pte containing a valid address. Fortunately we
      dont need these information in pte_clear - after all there is no
      mapping. The best fix is to remove the needless call to ptep_rcp_copy
      that contains the iske.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      2944a5c9