Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 29 3月, 2010 1 次提交
  3. 27 3月, 2010 1 次提交
  5. 17 3月, 2010 1 次提交
    • P
      Large page TLB flush · d4c430a8
      由 Paul Brook 提交于 
      QEMU uses a fixed page size for the CPU TLB.  If the guest uses large
pages then we effectively split these into multiple smaller pages, and
populate the corresponding TLB entries on demand.

When the guest invalidates the TLB by virtual address we must invalidate
all entries covered by the large page.  However the address used to
invalidate the entry may not be present in the QEMU TLB, so we do not
know which regions to clear.

Implementing a full vaiable size TLB is hard and slow, so just keep a
simple address/mask pair to record which addresses may have been mapped by
large pages.  If the guest invalidates this region then flush the
whole TLB.
Signed-off-by: NPaul Brook <paul@codesourcery.com>
      d4c430a8
  7. 14 3月, 2010 1 次提交
  9. 13 3月, 2010 7 次提交
  11. 04 3月, 2010 2 次提交
    • 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
    • M
      Add option to use file backed guest memory · c902760f
      由 Marcelo Tosatti 提交于 
      Port qemu-kvm's -mem-path and -mem-prealloc options. These are useful
for backing guest memory with huge pages via hugetlbfs.
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
CC: john cooper <john.cooper@redhat.com>
      c902760f
  13. 01 3月, 2010 5 次提交
  15. 10 2月, 2010 2 次提交
  17. 07 2月, 2010 2 次提交
  19. 06 2月, 2010 1 次提交
  21. 05 2月, 2010 2 次提交
  23. 04 2月, 2010 1 次提交
    • S
      kvm: Flush coalesced MMIO buffer periodly · 62a2744c
      由 Sheng Yang 提交于 
      The default action of coalesced MMIO is, cache the writing in buffer, until:
1. The buffer is full.
2. Or the exit to QEmu due to other reasons.

But this would result in a very late writing in some condition.
1. The each time write to MMIO content is small.
2. The writing interval is big.
3. No need for input or accessing other devices frequently.

This issue was observed in a experimental embbed system. The test image
simply print "test" every 1 seconds. The output in QEmu meets expectation,
but the output in KVM is delayed for seconds.

Per Avi's suggestion, I hooked flushing coalesced MMIO buffer in VGA update
handler. By this way, We don't need vcpu explicit exit to QEmu to
handle this issue.
Signed-off-by: NSheng Yang <sheng@linux.intel.com>
Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      62a2744c
  25. 27 1月, 2010 1 次提交
  27. 20 12月, 2009 1 次提交
  29. 19 12月, 2009 2 次提交
  31. 06 12月, 2009 1 次提交
  33. 30 11月, 2009 1 次提交
  35. 15 10月, 2009 1 次提交
  37. 05 10月, 2009 3 次提交
  39. 02 10月, 2009 2 次提交
  41. 12 9月, 2009 2 次提交