1. 09 Aug, 2012 1 commit
  2. 02 Aug, 2012 1 commit
    • Peter Maydell's avatar
      Support 'help' as a synonym for '?' in command line options · c8057f95
      Peter Maydell authored
      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: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  3. 13 May, 2012 1 commit
  4. 08 May, 2012 1 commit
  5. 02 May, 2012 1 commit
    • Stefan Weil's avatar
      qemu-timer: Fix limits for w32 mmtimer · 40f08e87
      Stefan Weil authored
      timeSetEvent only accepts delays in the range which is returned by
      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: default avatarStefan Weil <sw@weilnetz.de>
  6. 26 Apr, 2012 8 commits
  7. 16 Apr, 2012 1 commit
    • Peter Portante's avatar
      qemu-timer.c: Remove 250us timeouts · 158fd3ce
      Peter Portante authored
      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: default avatarPeter Portante <pportant@redhat.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  8. 30 Mar, 2012 1 commit
  9. 17 Feb, 2012 1 commit
  10. 26 Jan, 2012 1 commit
  11. 09 Nov, 2011 1 commit
  12. 21 Oct, 2011 8 commits
  13. 15 Sep, 2011 2 commits
  14. 02 Sep, 2011 1 commit
    • Anthony Liguori's avatar
      main: force enabling of I/O thread · 12d4536f
      Anthony Liguori authored
      Enabling the I/O thread by default seems like an important part of declaring
      1.0.  Besides allowing true SMP support with KVM, the I/O thread means that the
      TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines which
      currently requires a (racey) signal based alarm system.
      I know there have been concerns about performance.  I think so far the ones that
      have come up (virtio-net) are most likely due to secondary reasons like
      decreased batching.
      I think we ought to force enabling I/O thread early in 1.0 development and
      commit to resolving any lingering issues.
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
  15. 20 Aug, 2011 1 commit
  16. 23 Jul, 2011 3 commits
  17. 06 Jun, 2011 1 commit
  18. 27 Apr, 2011 3 commits
  19. 15 Apr, 2011 3 commits