Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 01 3月, 2010 1 次提交
  3. 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
  5. 21 12月, 2009 1 次提交
  7. 25 11月, 2009 1 次提交
  9. 02 10月, 2009 2 次提交
  11. 11 9月, 2009 1 次提交
  13. 24 8月, 2009 1 次提交
    • A
      Unbreak large mem support by removing kqemu · 4a1418e0
      由 Anthony Liguori 提交于 
      kqemu introduces a number of restrictions on the i386 target.  The worst is that
it prevents large memory from working in the default build.

Furthermore, kqemu is fundamentally flawed in a number of ways.  It relies on
the TSC as a time source which will not be reliable on a multiple processor
system in userspace.  Since most modern processors are multicore, this severely
limits the utility of kqemu.

kvm is a viable alternative for people looking to accelerate qemu and has the
benefit of being supported by the upstream Linux kernel.  If someone can
implement work arounds to remove the restrictions introduced by kqemu, I'm
happy to avoid and/or revert this patch.

N.B. kqemu will still function in the 0.11 series but this patch removes it from
the 0.12 series.

Paul, please Ack or Nack this patch.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      4a1418e0
  15. 28 7月, 2009 1 次提交
  17. 17 7月, 2009 2 次提交
  19. 10 7月, 2009 2 次提交
  21. 22 6月, 2009 1 次提交
    • G
      Handle init/sipi in a main cpu exec loop. (v2) · b09ea7d5
      由 Gleb Natapov 提交于 
      This should fix compilation problem in case of CONFIG_USER_ONLY.

Currently INIT/SIPI is handled in the context of CPU that sends IPI.
This patch changes this to handle them like all other events in a main
cpu exec loop. When KVM will gain thread per vcpu capability it will
be much more clear to handle those event by cpu thread itself and not
modify one cpu's state from the context of the other.
Signed-off-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      b09ea7d5
  23. 17 6月, 2009 1 次提交
  25. 16 6月, 2009 1 次提交
  27. 22 5月, 2009 1 次提交
  29. 19 5月, 2009 1 次提交
    • P
      Hardware convenience library · 1ad2134f
      由 Paul Brook 提交于 
      The only target dependency for most hardware is sizeof(target_phys_addr_t).
Build these files into a convenience library, and use that instead of
building for every target.

Remove and poison various target specific macros to avoid bogus target
dependencies creeping back in.

Big/Little endian is not handled because devices should not know or care
about this to start with.
Signed-off-by: NPaul Brook <paul@codesourcery.com>
      1ad2134f
  31. 01 5月, 2009 1 次提交
  33. 25 4月, 2009 1 次提交
  35. 19 4月, 2009 1 次提交
  37. 12 4月, 2009 1 次提交
  39. 11 4月, 2009 1 次提交
  41. 10 4月, 2009 1 次提交
  43. 08 3月, 2009 1 次提交
  45. 11 2月, 2009 1 次提交
  47. 02 2月, 2009 1 次提交
  49. 27 1月, 2009 1 次提交
  51. 25 1月, 2009 1 次提交
  53. 23 1月, 2009 2 次提交
  55. 15 1月, 2009 2 次提交
    • B
      Add noreturn function attribute · 7d99a001
      由 blueswir1 提交于 
      Introduce noreturn attribute and attach it to cpu_loop_exit as well as
interrupt/exception helpers for i386. This avoids a bunch of gcc4
warnings.

[ Note that this patch comes with a workaround to include qemu-common.h
even in cases where is currently causes conflicts with dyngen-exec.h.
I've been told that these conflicts will get resolved in the future
(/me will try to have a look as well - as time permits). ]
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>


git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6303 c046a42c-6fe2-441c-8c8c-71466251a162
      7d99a001
    • M
      Remove all traces of __powerpc__ · e58ffeb3
      由 malc 提交于 
      According to $GCC/gcc/config/rs6000/rs6000-c.c _ARCH_PPC is the
ubiquitous define which should be used to test whether gcc targets
PowerPC, on 64bit platforms _ARCH_PPC64 will be also defined.

git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6301 c046a42c-6fe2-441c-8c8c-71466251a162
      e58ffeb3
  57. 05 1月, 2009 1 次提交
  59. 11 12月, 2008 1 次提交
  61. 10 12月, 2008 1 次提交
    • A
      KVM: Coalesced MMIO support · f65ed4c1
      由 aliguori 提交于 
      MMIO exits are more expensive in KVM or Xen than in QEMU because they 
involve, at least, privilege transitions.  However, MMIO write 
operations can be effectively batched if those writes do not have side 
effects.

Good examples of this include VGA pixel operations when in a planar 
mode.  As it turns out, we can get a nice boost in other areas too.  
Laurent mentioned a 9.7% performance boost in iperf with the coalesced 
MMIO changes for the e1000 when he originally posted this work for KVM.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>



git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5961 c046a42c-6fe2-441c-8c8c-71466251a162
      f65ed4c1
  63. 09 12月, 2008 2 次提交
  65. 08 12月, 2008 1 次提交
  67. 02 12月, 2008 1 次提交