1. 12 5月, 2010 1 次提交
  2. 04 3月, 2010 1 次提交
    • J
      KVM: Rework VCPU state writeback API · ea375f9a
      Jan Kiszka 提交于
      This grand cleanup drops all reset and vmsave/load related
      synchronization points in favor of four(!) generic hooks:
      
      - cpu_synchronize_all_states in qemu_savevm_state_complete
        (initial sync from kernel before vmsave)
      - cpu_synchronize_all_post_init in qemu_loadvm_state
        (writeback after vmload)
      - cpu_synchronize_all_post_init in main after machine init
      - cpu_synchronize_all_post_reset in qemu_system_reset
        (writeback after system reset)
      
      These writeback points + the existing one of VCPU exec after
      cpu_synchronize_state map on three levels of writeback:
      
      - KVM_PUT_RUNTIME_STATE (during runtime, other VCPUs continue to run)
      - KVM_PUT_RESET_STATE   (on synchronous system reset, all VCPUs stopped)
      - KVM_PUT_FULL_STATE    (on init or vmload, all VCPUs stopped as well)
      
      This level is passed to the arch-specific VCPU state writing function
      that will decide which concrete substates need to be written. That way,
      no writer of load, save or reset functions that interact with in-kernel
      KVM states will ever have to worry about synchronization again. That
      also means that a lot of reasons for races, segfaults and deadlocks are
      eliminated.
      
      cpu_synchronize_state remains untouched, just as Anthony suggested. We
      continue to need it before reading or writing of VCPU states that are
      also tracked by in-kernel KVM subsystems.
      
      Consequently, this patch removes many cpu_synchronize_state calls that
      are now redundant, just like remaining explicit register syncs.
      Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      ea375f9a
  3. 14 2月, 2010 2 次提交
    • A
      PPC: Add timer when running KVM · c6a94ba5
      Alexander Graf 提交于
      For some odd reason we sometimes hang inside KVM forever. I'd guess it's
      a race condition where we actually have a level triggered interrupt, but
      the infrastructure can't expose that yet, so the guest ACKs it, goes to
      sleep and never gets notified that there's still an interrupt pending.
      
      As a quick workaround, let's just wake up every 500 ms. That way we can
      assure that we're always reinjecting interrupts in time.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      c6a94ba5
    • A
      PPC: tell the guest about the time base frequency · dc333cd6
      Alexander Graf 提交于
      Our guest systems need to know by how much the timebase increases every second,
      so there usually is a "timebase-frequency" property in the cpu leaf of the
      device tree.
      
      This property is missing in OpenBIOS.
      
      With qemu, Linux's fallback timebase speed and qemu's internal timebase speed
      match up. With KVM, that is no longer true. The guest is running at the same
      timebase speed as the host.
      
      This leads to massive timing problems. On my test machine, a "sleep 2" takes
      about 14 seconds with KVM enabled.
      
      This patch exports the timebase frequency to OpenBIOS, so it can then put them
      into the device tree.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      dc333cd6
  4. 19 12月, 2009 1 次提交
  5. 04 12月, 2009 1 次提交
  6. 17 11月, 2009 1 次提交
  7. 22 7月, 2009 2 次提交
  8. 16 12月, 2008 1 次提交