Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 23 8月, 2013 3 次提交
  3. 19 8月, 2013 1 次提交
  5. 12 6月, 2013 1 次提交
    • M
      main-loop: do not include slirp/slirp.h, use libslirp.h instead · 520b6dd4
      由 Michael Tokarev 提交于 
      The header slirp/slirp.h is an internal header for slirp, and
main-loop.c does not use internals from there.  Instead, it uses
public functions (slirp_update_timeout(), slirp_pollfds_fill()
etc) which are declared in slirp/libslirp.h.

Including slirp/slirp.h is somewhat dangerous since it redefines
errno on WIN32, so any file including it may misbehave wrt errno.

Unfortunately libslirp isn't self-contained, it needs declaration
of struct in_addr, which is provided by qemu/sockets.h.  Maybe
instead of #including qemu/sockets.h before libslirp.h, it is
better to make the latter self-contained.
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      520b6dd4
  7. 17 5月, 2013 2 次提交
  9. 06 4月, 2013 1 次提交
    • A
      main-loop: drop the BQL if the I/O appears to be spinning · 893986fe
      由 Anthony Liguori 提交于 
      The char-flow refactoring introduced a busy-wait that depended on
an action from the VCPU thread.  However, the VCPU thread could
never take that action because the busy-wait starved the VCPU thread
of the BQL because it never dropped the mutex while running select.

Paolo doesn't want to drop this optimization for fear that we will
stop detecting these busy waits.  I'm afraid to keep this optimization
even with the busy-wait fixed because I think a similar problem can
occur just with heavy I/O thread load manifesting itself as VCPU pauses.

As a compromise, introduce an artificial timeout after a thousand
iterations but print a rate limited warning when this happens.  This
let's us still detect when this condition occurs without it being
a fatal error.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Message-id: 1365169560-11012-1-git-send-email-aliguori@us.ibm.com
      893986fe
  11. 15 3月, 2013 1 次提交
  13. 22 2月, 2013 6 次提交
  15. 10 1月, 2013 1 次提交
    • F
      Check return values from g_poll and select · 5e3bc735
      由 Fabien Chouteau 提交于 
      The current implementation of os_host_main_loop_wait() on Windows,
returns 1 only when a g_poll() event occurs because the return value of
select() is overridden. This is wrong as we may skip a socket event, as
shown in this example:

1. select() returns 0
2. g_poll() returns 1  (socket event occurs)
3. os_host_main_loop_wait() returns 1
4. qemu_iohandler_poll() sees no socket event because select() has
   return before the event occurs
5. select() returns 1
6. g_poll() returns 0 (g_poll overrides select's return value)
7. os_host_main_loop_wait() returns 0
8. qemu_iohandler_poll() doesn't check for socket events because the
   return value of os_host_main_loop_wait() is zero.
9. goto 5

This patch use one variable for each of these return values, so we don't
miss a select() event anymore.

Also move the call to select() after g_poll(), this will improve latency
as we don't have to go through two os_host_main_loop_wait() calls to
detect a socket event.
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFabien Chouteau <chouteau@adacore.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      5e3bc735
  17. 19 12月, 2012 2 次提交
  19. 11 12月, 2012 1 次提交
  21. 03 11月, 2012 2 次提交
  23. 30 10月, 2012 7 次提交
  25. 01 5月, 2012 1 次提交
  27. 28 4月, 2012 1 次提交
  29. 27 4月, 2012 1 次提交
  31. 16 4月, 2012 1 次提交
  33. 07 4月, 2012 5 次提交
  35. 03 4月, 2012 1 次提交
  37. 02 2月, 2012 2 次提交
    • M
      main-loop: For tools, initialize timers as part of qemu_init_main_loop() · d34e8f6e
      由 Michael Roth 提交于 
      In some cases initializing the alarm timers can lead to non-negligable
overhead from programs that link against qemu-tool.o. At least,
setting a max-resolution WinMM alarm timer via mm_start_timer() (the
current default for Windows) can increase the "tick rate" on Windows
OSs and affect frequency scaling, and in the case of tools that run
in guest OSs such has qemu-ga, the impact can be fairly dramatic
(+20%/20% user/sys time on a core 2 processor was observed from an idle
Windows XP guest).

This patch doesn't address the issue directly (not sure what a good
solution would be for Windows, or what other situations it might be
noticeable), but it at least limits the scope of the issue to programs
that "opt-in" to using the main-loop.c functions by only enabling alarm
timers when qemu_init_main_loop() is called, which is already required
to make use of those facilities, so existing users shouldn't be
affected.
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      d34e8f6e
    • M
      main-loop: Fix SetEvent() on uninitialized handle on win32 · ee77dfb2
      由 Michael Roth 提交于 
      The __attribute__((constructor)) init_main_loop() automatically get
called if qemu-tool.o is linked in. On win32, this leads to
a qemu_notify_event() call which attempts to SetEvent() on a HANDLE that
won't be initialized until qemu_init_main_loop() is manually called,
breaking qemu-tools.o programs on Windows at runtime.

This patch checks for an initialized event handle before attempting to
set it, which is analoguous to how we deal with an unitialized
io_thread_fd in the posix implementation.
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      ee77dfb2