Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 23 8月, 2013 7 次提交
  3. 22 8月, 2013 4 次提交
  5. 13 4月, 2013 1 次提交
  7. 19 12月, 2012 5 次提交
  9. 10 11月, 2012 1 次提交
  11. 05 11月, 2012 1 次提交
  13. 03 11月, 2012 1 次提交
  15. 30 10月, 2012 1 次提交
  17. 28 10月, 2012 1 次提交
  19. 23 9月, 2012 1 次提交
  21. 04 9月, 2012 1 次提交
  23. 10 8月, 2012 1 次提交
  25. 03 8月, 2012 1 次提交
    • P
      Support 'help' as a synonym for '?' in command line options · c8057f95
      由 Peter Maydell 提交于 
      For command line options which permit '?' meaning 'please list the
permitted values', add support for 'help' as a synonym, by abstracting
the check out into a helper function.

This change means that in some cases where we were being lazy in
our string parsing, "?junk" will now be rejected as an invalid option
rather than being (undocumentedly) treated the same way as "?".

Update the documentation to use 'help' rather than '?', since '?'
is a shell metacharacter and thus prone to fail confusingly if there
is a single character filename in the current working directory and
the '?' has not been escaped. It's therefore better to steer users
towards 'help', though '?' is retained for backwards compatibility.

We do not, however, update the output of the system emulator's -help
(or any documentation autogenerated from the qemu-options.hx which
is the source of the -help text) because libvirt parses our -help
output and will break. At a later date when QEMU provides a better
interface so libvirt can avoid having to do this, we can update the
-help text too.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      c8057f95
  27. 14 5月, 2012 1 次提交
  29. 09 5月, 2012 1 次提交
  31. 03 5月, 2012 1 次提交
    • S
      qemu-timer: Fix limits for w32 mmtimer · 40f08e87
      由 Stefan Weil 提交于 
      timeSetEvent only accepts delays in the range which is returned by
timeGetDevCaps.

The lower limit is typically 1 (= 1 ms), so the constant value of 1
in the old code usually worked.

The upper limit can be as low as 10000 ms, so the latest changes in
QEMU's timer handling which introduced timeout values above that limit
could result in failures of timeSetEvent when the timer was re-armed.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
      40f08e87
  33. 27 4月, 2012 8 次提交
  35. 17 4月, 2012 1 次提交
    • P
      qemu-timer.c: Remove 250us timeouts · 158fd3ce
      由 Peter Portante 提交于 
      Basically, the main wait loop calls qemu_run_all_timers() unconditionally. The
first thing this routine used to do is to see if a timer had been serviced,
and then reset the loop timeout to the next deadline.

However, the new deadlines had not been calculated at that point, as
qemu_run_timers() had not been called yet for each of the clocks. So
qemu_rearm_alarm_timer() would end up with a negative or zero deadline, and
default to setting a 250us timeout for the loop.

As qemu_run_timers() is called for each clock, the real deadlines would be put
in place, but because a loop timeout was already set, the loop timeout would
not be changed.

Once that 250us timeout fired, the real deadline would be used for the
subsequent timeout.

For idle VMs, this effectively doubles the number of times through the loop,
doubling the number of select() system calls, timer calls, etc. putting added
scheduling pressure on the kernel. And under cgroups, this really causes a big
problem because the cgroup code does not scale well.

By simply running the timers before trying to rearm the timer, we always rearm
with a non-zero deadline, effectively halving the number of system calls.
Signed-off-by: NPeter Portante <pportant@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      158fd3ce
  37. 30 3月, 2012 1 次提交
  39. 17 2月, 2012 1 次提交