Skip to content
Snippets Groups Projects
  1. Mar 09, 2018
  2. Mar 08, 2018
  3. Mar 05, 2018
  4. Mar 02, 2018
    • Markus Armbruster's avatar
      qapi: Empty out qapi-schema.json · 112ed241
      Markus Armbruster authored
      
      The previous commit improved compile time by including less of the
      generated QAPI headers.  This is impossible for stuff defined directly
      in qapi-schema.json, because that ends up in headers that that pull in
      everything.
      
      Move everything but include directives from qapi-schema.json to new
      sub-module qapi/misc.json, then include just the "misc" shard where
      possible.
      
      It's possible everywhere, except:
      
      * monitor.c needs qmp-command.h to get qmp_init_marshal()
      
      * monitor.c, ui/vnc.c and the generated qapi-event-FOO.c need
        qapi-event.h to get enum QAPIEvent
      
      Perhaps we'll get rid of those some other day.
      
      Adding a type to qapi/migration.json now recompiles some 120 instead
      of 2300 out of 5100 objects.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180211093607.27351-25-armbru@redhat.com>
      [eblake: rebase to master]
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      112ed241
    • Markus Armbruster's avatar
      Include less of the generated modular QAPI headers · 9af23989
      Markus Armbruster authored
      
      In my "build everything" tree, a change to the types in
      qapi-schema.json triggers a recompile of about 4800 out of 5100
      objects.
      
      The previous commit split up qmp-commands.h, qmp-event.h, qmp-visit.h,
      qapi-types.h.  Each of these headers still includes all its shards.
      Reduce compile time by including just the shards we actually need.
      
      To illustrate the benefits: adding a type to qapi/migration.json now
      recompiles some 2300 instead of 4800 objects.  The next commit will
      improve it further.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180211093607.27351-24-armbru@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Reviewed-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      [eblake: rebase to master]
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      9af23989
    • Stefan Hajnoczi's avatar
      block: extract AIO_WAIT_WHILE() from BlockDriverState · 7719f3c9
      Stefan Hajnoczi authored
      
      BlockDriverState has the BDRV_POLL_WHILE() macro to wait on event loop
      activity while a condition evaluates to true.  This is used to implement
      synchronous operations where it acts as a condvar between the IOThread
      running the operation and the main loop waiting for the operation.  It
      can also be called from the thread that owns the AioContext and in that
      case it's just a nested event loop.
      
      BlockBackend needs this behavior but doesn't always have a
      BlockDriverState it can use.  This patch extracts BDRV_POLL_WHILE() into
      the AioWait abstraction, which can be used with AioContext and isn't
      tied to BlockDriverState anymore.
      
      This feature could be built directly into AioContext but then all users
      would kick the event loop even if they signal different conditions.
      Imagine an AioContext with many BlockDriverStates, each time a request
      completes any waiter would wake up and re-check their condition.  It's
      nicer to keep a separate AioWait object for each condition instead.
      
      Please see "block/aio-wait.h" for details on the API.
      
      The name AIO_WAIT_WHILE() avoids the confusion between AIO_POLL_WHILE()
      and AioContext polling.
      
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      7719f3c9
  5. Mar 01, 2018
  6. Feb 19, 2018
    • Marcel Apfelbaum's avatar
      mem: add share parameter to memory-backend-ram · 06329cce
      Marcel Apfelbaum authored
      
      Currently only file backed memory backend can
      be created with a "share" flag in order to allow
      sharing guest RAM with other processes in the host.
      
      Add the "share" flag also to RAM Memory Backend
      in order to allow remapping parts of the guest RAM
      to different host virtual addresses. This is needed
      by the RDMA devices in order to remap non-contiguous
      QEMU virtual addresses to a contiguous virtual address range.
      
      Moved the "share" flag to the Host Memory base class,
      modified phys_mem_alloc to include the new parameter
      and a new interface memory_region_init_ram_shared_nomigrate.
      
      There are no functional changes if the new flag is not used.
      
      Reviewed-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: default avatarMarcel Apfelbaum <marcel@redhat.com>
      06329cce
  7. Feb 15, 2018
  8. Feb 10, 2018
  9. Feb 09, 2018
  10. Feb 08, 2018
  11. Feb 07, 2018
  12. Feb 05, 2018
    • Daniel P. Berrangé's avatar
      sockets: fix parsing of ipv4/ipv6 opts in parse_socket_addr · 3e32370a
      Daniel P. Berrangé authored
      
      The inet_parse() function looks for 'ipv4' and 'ipv6' flags, but only
      treats them as bare bool flags. The normal QemuOpts parsing would allow
      on/off values to be set too.
      
      This updates inet_parse() so that its handling of the 'ipv4' and 'ipv6'
      flags matches that done by QemuOpts.
      
      This impacts the NBD block driver parsing the legacy filename syntax and
      the migration code parsing the socket scheme.
      
      Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
      Message-Id: <20180125171412.21627-1-berrange@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      3e32370a
    • Greg Kurz's avatar
      readline: don't free completions in readline_free() · 4183e2ea
      Greg Kurz authored
      
      Since commit e5dc1a6c, QEMU aborts on exit if completion was used
      in the monitor:
      
      *** Error in `obj/ppc64-softmmu/qemu-system-ppc64': double free or
       corruption (fasttop): 0x00000100331069d0 ***
      
       /home/greg/Work/qemu/qemu-spapr/util/readline.c:514
       /home/greg/Work/qemu/qemu-spapr/monitor.c:586
       /home/greg/Work/qemu/qemu-spapr/monitor.c:4125
       argv=<optimized out>, envp=<optimized out>) at
       /home/greg/Work/qemu/qemu-spapr/vl.c:4795
      
      Completion strings are not persistent accross completions (why would
      they?). They are allocated under readline_completion(), which already
      takes care of freeing them before returning.
      
      Maybe all completion related bits should be moved out of ReadLineState
      to a dedicated structure ?
      
      In the meantime, let's drop the offending lines from readline_free()
      to fix the crash.
      
      Signed-off-by: default avatarGreg Kurz <groug@kaod.org>
      Message-Id: <151627206353.4505.4602428849861610759.stgit@bahia.lan>
      Fixes: e5dc1a6c
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      4183e2ea
  13. Jan 24, 2018
  14. Jan 23, 2018
  15. Jan 19, 2018
  16. Jan 18, 2018
  17. Jan 16, 2018
    • Alex Bennée's avatar
    • Marc-André Lureau's avatar
      qemu-config: fix leak in query-command-line-options · b11e20fb
      Marc-André Lureau authored
      
      Direct leak of 160 byte(s) in 4 object(s) allocated from:
          #0 0x55ed7678cda8 in calloc (/home/elmarco/src/qq/build/x86_64-softmmu/qemu-system-x86_64+0x797da8)
          #1 0x7f3f5e725f75 in g_malloc0 /home/elmarco/src/gnome/glib/builddir/../glib/gmem.c:124
          #2 0x55ed778aa3a7 in query_option_descs /home/elmarco/src/qq/util/qemu-config.c:60:16
          #3 0x55ed778aa307 in get_drive_infolist /home/elmarco/src/qq/util/qemu-config.c:140:19
          #4 0x55ed778a9f40 in qmp_query_command_line_options /home/elmarco/src/qq/util/qemu-config.c:254:36
          #5 0x55ed76d4868c in qmp_marshal_query_command_line_options /home/elmarco/src/qq/build/qmp-marshal.c:3078:14
          #6 0x55ed77855dd5 in do_qmp_dispatch /home/elmarco/src/qq/qapi/qmp-dispatch.c:104:5
          #7 0x55ed778558cc in qmp_dispatch /home/elmarco/src/qq/qapi/qmp-dispatch.c:131:11
          #8 0x55ed768b592f in handle_qmp_command /home/elmarco/src/qq/monitor.c:3840:11
          #9 0x55ed7786ccfe in json_message_process_token /home/elmarco/src/qq/qobject/json-streamer.c:105:5
          #10 0x55ed778fe37c in json_lexer_feed_char /home/elmarco/src/qq/qobject/json-lexer.c:323:13
          #11 0x55ed778fdde6 in json_lexer_feed /home/elmarco/src/qq/qobject/json-lexer.c:373:15
          #12 0x55ed7786cd83 in json_message_parser_feed /home/elmarco/src/qq/qobject/json-streamer.c:124:12
          #13 0x55ed768b559e in monitor_qmp_read /home/elmarco/src/qq/monitor.c:3882:5
          #14 0x55ed77714f29 in qemu_chr_be_write_impl /home/elmarco/src/qq/chardev/char.c:167:9
          #15 0x55ed77714fde in qemu_chr_be_write /home/elmarco/src/qq/chardev/char.c:179:9
          #16 0x55ed7772ffad in tcp_chr_read /home/elmarco/src/qq/chardev/char-socket.c:440:13
          #17 0x55ed7777113b in qio_channel_fd_source_dispatch /home/elmarco/src/qq/io/channel-watch.c:84:12
          #18 0x7f3f5e71d90b in g_main_dispatch /home/elmarco/src/gnome/glib/builddir/../glib/gmain.c:3182
          #19 0x7f3f5e71e7ac in g_main_context_dispatch /home/elmarco/src/gnome/glib/builddir/../glib/gmain.c:3847
          #20 0x55ed77886ffc in glib_pollfds_poll /home/elmarco/src/qq/util/main-loop.c:214:9
          #21 0x55ed778865fd in os_host_main_loop_wait /home/elmarco/src/qq/util/main-loop.c:261:5
          #22 0x55ed77886222 in main_loop_wait /home/elmarco/src/qq/util/main-loop.c:515:11
          #23 0x55ed76d2a4df in main_loop /home/elmarco/src/qq/vl.c:1995:9
          #24 0x55ed76d1cb4a in main /home/elmarco/src/qq/vl.c:4914:5
          #25 0x7f3f555f6039 in __libc_start_main (/lib64/libc.so.6+0x21039)
      
      Signed-off-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: default avatarEric Blake <eblake@redhat.com>
      Message-Id: <20180104160523.22995-14-marcandre.lureau@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      b11e20fb
    • Marc-André Lureau's avatar
      readline: add a free function · e5dc1a6c
      Marc-André Lureau authored
      
      Fixes leaks such as:
      
      Direct leak of 2 byte(s) in 1 object(s) allocated from:
          #0 0x7eff58beb850 in malloc (/lib64/libasan.so.4+0xde850)
          #1 0x7eff57942f0c in g_malloc ../glib/gmem.c:94
          #2 0x7eff579431cf in g_malloc_n ../glib/gmem.c:331
          #3 0x7eff5795f6eb in g_strdup ../glib/gstrfuncs.c:363
          #4 0x55db720f1d46 in readline_hist_add /home/elmarco/src/qq/util/readline.c:258
          #5 0x55db720f2d34 in readline_handle_byte /home/elmarco/src/qq/util/readline.c:387
          #6 0x55db71539d00 in monitor_read /home/elmarco/src/qq/monitor.c:3896
          #7 0x55db71f9be35 in qemu_chr_be_write_impl /home/elmarco/src/qq/chardev/char.c:167
          #8 0x55db71f9bed3 in qemu_chr_be_write /home/elmarco/src/qq/chardev/char.c:179
          #9 0x55db71fa013c in fd_chr_read /home/elmarco/src/qq/chardev/char-fd.c:66
          #10 0x55db71fe18a8 in qio_channel_fd_source_dispatch /home/elmarco/src/qq/io/channel-watch.c:84
          #11 0x7eff5793a90b in g_main_dispatch ../glib/gmain.c:3182
          #12 0x7eff5793b7ac in g_main_context_dispatch ../glib/gmain.c:3847
          #13 0x55db720af3bd in glib_pollfds_poll /home/elmarco/src/qq/util/main-loop.c:214
          #14 0x55db720af505 in os_host_main_loop_wait /home/elmarco/src/qq/util/main-loop.c:261
          #15 0x55db720af6d6 in main_loop_wait /home/elmarco/src/qq/util/main-loop.c:515
          #16 0x55db7184e0de in main_loop /home/elmarco/src/qq/vl.c:1995
          #17 0x55db7185e956 in main /home/elmarco/src/qq/vl.c:4914
          #18 0x7eff4ea17039 in __libc_start_main (/lib64/libc.so.6+0x21039)
      
      (while at it, use g_new0(ReadLineState), it's a bit easier to read)
      
      Signed-off-by: default avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      Reviewed-by: default avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Message-Id: <20180104160523.22995-11-marcandre.lureau@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      e5dc1a6c
  18. Dec 21, 2017
    • Yang Zhong's avatar
      rcu: reduce more than 7MB heap memory by malloc_trim() · 5a22ab71
      Yang Zhong authored
      
      Since there are some issues in memory alloc/free machenism
      in glibc for little chunk memory, if Qemu frequently
      alloc/free little chunk memory, the glibc doesn't alloc
      little chunk memory from free list of glibc and still
      allocate from OS, which make the heap size bigger and bigger.
      
      This patch introduce malloc_trim(), which will free heap
      memory when there is no rcu call during rcu thread loop.
      malloc_trim() can be enabled/disabled by --enable-malloc-trim/
      --disable-malloc-trim in the Qemu configure command. The
      default malloc_trim() is enabled for libc.
      
      Below are test results from smaps file.
      (1)without patch
      55f0783e1000-55f07992a000 rw-p 00000000 00:00 0  [heap]
      Size:              21796 kB
      Rss:               14260 kB
      Pss:               14260 kB
      
      (2)with patch
      55cc5fadf000-55cc61008000 rw-p 00000000 00:00 0  [heap]
      Size:              21668 kB
      Rss:                6940 kB
      Pss:                6940 kB
      
      Signed-off-by: default avatarYang Zhong <yang.zhong@intel.com>
      Message-Id: <1513775806-19779-1-git-send-email-yang.zhong@intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      5a22ab71
    • Daniel P. Berrangé's avatar
      sockets: remove obsolete code that updated listen address · 62473511
      Daniel P. Berrangé authored
      
      When listening on unix/tcp sockets there was optional code that would update
      the original SocketAddress struct with the info about the actual address that
      was listened on. Since the conversion of everything to QIOChannelSocket, no
      remaining caller made use of this feature. It has been replaced with the ability
      to query the listen address after the fact using the function
      qio_channel_socket_get_local_address. This is a better model when the input
      address can result in listening on multiple distinct sockets.
      
      Signed-off-by: default avatarDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Message-Id: <20171212111219.32601-1-berrange@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      62473511
  19. Dec 20, 2017
    • linzhecheng's avatar
      qemu-thread: fix races on threads that exit very quickly · 68a93982
      linzhecheng authored
      If we create a thread with QEMU_THREAD_DETACHED mode, QEMU may get a segfault with low probability.
      
      The backtrace is:
         #0  0x00007f46c60291d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
         #1  0x00007f46c602a8c8 in __GI_abort () at abort.c:90
         #2  0x00000000008543c9 in PAT_abort ()
         #3  0x000000000085140d in patchIllInsHandler ()
         #4  <signal handler called>
         #5  pthread_detach (th=139933037614848) at pthread_detach.c:50
         #6  0x0000000000829759 in qemu_thread_create (thread=thread@entry=0x7ffdaa8205e0, name=name@entry=0x94d94a "io-task-worker", start_routine=start_routine@entry=0x7eb9a0 <qio_task_thread_worker>,
             arg=arg@entry=0x3f5cf70, mode=mode@entry=1) at util/qemu_thread_posix.c:512
         #7  0x00000000007ebc96 in qio_task_run_in_thread (task=0x31db2c0, worker=worker@entry=0x7e7e40 <qio_channel_socket_connect_worker>, opaque=0xcd23380, destroy=0x7f1180 <qapi_free_SocketAddress>)
             at io/task.c:141
         #8  0x00000000007e7f33 in qio_channel_socket_connect_async (ioc=ioc@entry=0x626c0b0, addr=<optimized out>, callback=callback@entry=0x55e080 <qemu_chr_socket_connected>, opaque=opaque@entry=0x42862c0,
             destroy=destroy@entry=0x0) at io/channel_socket.c:194
         #9  0x000000000055bdd1 in socket_reconnect_timeout (opaque=0x42862c0) at qemu_char.c:4744
         #10 0x00007f46c72483b3 in g_timeout_dispatch () from /usr/lib64/libglib-2.0.so.0
         #11 0x00007f46c724799a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
         #12 0x000000000076c646 in glib_pollfds_poll () at main_loop.c:228
         #13 0x000000000076c6eb in os_host_main_loop_wait (timeout=348000000) at main_loop.c:273
         #14 0x000000000076c815 in main_loop_wait (nonblocking=nonblocking@entry=0) at main_loop.c:521
         #15 0x000000000056a511 in main_loop () at vl.c:2076
         #16 0x0000000000420705 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4940
      
      The cause of this problem is a glibc bug; for more information, see
      https://sourceware.org/bugzilla/show_bug.cgi?id=19951
      
      .
      The solution for this bug is to use pthread_attr_setdetachstate.
      
      There is a similar issue with pthread_setname_np, which is moved
      from creating thread to created thread.
      
      Signed-off-by: default avatarlinzhecheng <linzhecheng@huawei.com>
      Message-Id: <20171128044656.10592-1-linzhecheng@huawei.com>
      Reviewed-by: default avatarFam Zheng <famz@redhat.com>
      [Simplify the code by removing qemu_thread_set_name, and free the arguments
       before invoking the start routine. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      68a93982
    • Paolo Bonzini's avatar
      memfd: fix configure test · 75e5b70e
      Paolo Bonzini authored
      
      Recent glibc added memfd_create in sys/mman.h.  This conflicts with
      the definition in util/memfd.c:
      
          /builddir/build/BUILD/qemu-2.11.0-rc1/util/memfd.c:40:12: error: static declaration of memfd_create follows non-static declaration
      
      Fix the configure test, and remove the sys/memfd.h inclusion since the
      file actually does not exist---it is a typo in the memfd_create(2) man
      page.
      
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      75e5b70e
Loading