1. 24 10月, 2016 5 次提交
  2. 13 10月, 2016 1 次提交
  3. 10 10月, 2016 1 次提交
    • D
      net: don't poke at chardev internal QemuOpts · 0a73336d
      Daniel P. Berrange 提交于
      The vhost-user & colo code is poking at the QemuOpts instance
      in the CharDriverState struct, not realizing that it is valid
      for this to be NULL. e.g. the following crash shows a codepath
      where it will be NULL:
      
       Program terminated with signal SIGSEGV, Segmentation fault.
       #0  0x000055baf6ab4adc in qemu_opt_foreach (opts=0x0, func=0x55baf696b650 <net_vhost_chardev_opts>, opaque=0x7ffc51368c00, errp=0x7ffc51368e48) at util/qemu-option.c:617
       617         QTAILQ_FOREACH(opt, &opts->head, next) {
       [Current thread is 1 (Thread 0x7f1d4970bb40 (LWP 6603))]
       (gdb) bt
       #0  0x000055baf6ab4adc in qemu_opt_foreach (opts=0x0, func=0x55baf696b650 <net_vhost_chardev_opts>, opaque=0x7ffc51368c00, errp=0x7ffc51368e48) at util/qemu-option.c:617
       #1  0x000055baf696b7da in net_vhost_parse_chardev (opts=0x55baf8ff9260, errp=0x7ffc51368e48) at net/vhost-user.c:314
       #2  0x000055baf696b985 in net_init_vhost_user (netdev=0x55baf8ff9250, name=0x55baf879d270 "hostnet2", peer=0x0, errp=0x7ffc51368e48) at net/vhost-user.c:360
       #3  0x000055baf6960216 in net_client_init1 (object=0x55baf8ff9250, is_netdev=true, errp=0x7ffc51368e48) at net/net.c:1051
       #4  0x000055baf6960518 in net_client_init (opts=0x55baf776e7e0, is_netdev=true, errp=0x7ffc51368f00) at net/net.c:1108
       #5  0x000055baf696083f in netdev_add (opts=0x55baf776e7e0, errp=0x7ffc51368f00) at net/net.c:1186
       #6  0x000055baf69608c7 in qmp_netdev_add (qdict=0x55baf7afaf60, ret=0x7ffc51368f50, errp=0x7ffc51368f48) at net/net.c:1205
       #7  0x000055baf6622135 in handle_qmp_command (parser=0x55baf77fb590, tokens=0x7f1d24011960) at /path/to/qemu.git/monitor.c:3978
       #8  0x000055baf6a9d099 in json_message_process_token (lexer=0x55baf77fb598, input=0x55baf75acd20, type=JSON_RCURLY, x=113, y=19) at qobject/json-streamer.c:105
       #9  0x000055baf6abf7aa in json_lexer_feed_char (lexer=0x55baf77fb598, ch=125 '}', flush=false) at qobject/json-lexer.c:319
       #10 0x000055baf6abf8f2 in json_lexer_feed (lexer=0x55baf77fb598, buffer=0x7ffc51369170 "}R\204\367\272U", size=1) at qobject/json-lexer.c:369
       #11 0x000055baf6a9d13c in json_message_parser_feed (parser=0x55baf77fb590, buffer=0x7ffc51369170 "}R\204\367\272U", size=1) at qobject/json-streamer.c:124
       #12 0x000055baf66221f7 in monitor_qmp_read (opaque=0x55baf77fb530, buf=0x7ffc51369170 "}R\204\367\272U", size=1) at /path/to/qemu.git/monitor.c:3994
       #13 0x000055baf6757014 in qemu_chr_be_write_impl (s=0x55baf7610a40, buf=0x7ffc51369170 "}R\204\367\272U", len=1) at qemu-char.c:387
       #14 0x000055baf6757076 in qemu_chr_be_write (s=0x55baf7610a40, buf=0x7ffc51369170 "}R\204\367\272U", len=1) at qemu-char.c:399
       #15 0x000055baf675b3b0 in tcp_chr_read (chan=0x55baf90244b0, cond=G_IO_IN, opaque=0x55baf7610a40) at qemu-char.c:2927
       #16 0x000055baf6a5d655 in qio_channel_fd_source_dispatch (source=0x55baf7610df0, callback=0x55baf675b25a <tcp_chr_read>, user_data=0x55baf7610a40) at io/channel-watch.c:84
       #17 0x00007f1d3e80cbbd in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
       #18 0x000055baf69d3720 in glib_pollfds_poll () at main-loop.c:213
       #19 0x000055baf69d37fd in os_host_main_loop_wait (timeout=126000000) at main-loop.c:258
       #20 0x000055baf69d38ad in main_loop_wait (nonblocking=0) at main-loop.c:506
       #21 0x000055baf676587b in main_loop () at vl.c:1908
       #22 0x000055baf676d3bf in main (argc=101, argv=0x7ffc5136a6c8, envp=0x7ffc5136a9f8) at vl.c:4604
       (gdb) p opts
       $1 = (QemuOpts *) 0x0
      
      The crash occurred when attaching vhost-user net via QMP:
      
      {
          "execute": "chardev-add",
          "arguments": {
              "id": "charnet2",
              "backend": {
                  "type": "socket",
                  "data": {
                      "addr": {
                          "type": "unix",
                          "data": {
                              "path": "/var/run/openvswitch/vhost-user1"
                          }
                      },
                      "wait": false,
                      "server": false
                  }
              }
          },
          "id": "libvirt-19"
      }
      {
          "return": {
      
          },
          "id": "libvirt-19"
      }
      {
          "execute": "netdev_add",
          "arguments": {
              "type": "vhost-user",
              "chardev": "charnet2",
              "id": "hostnet2"
          },
          "id": "libvirt-20"
      }
      
      Code using chardevs should not be poking at the internals of the
      CharDriverState struct. What vhost-user wants is a chardev that is
      operating as reconnectable network service, along with the ability
      to do FD passing over the connection. The colo code simply wants
      a network service. Add a feature concept to the char drivers so
      that chardev users can query the actual features they wish to have
      supported. The QemuOpts member is removed to prevent future mistakes
      in this area.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      0a73336d
  4. 04 10月, 2016 1 次提交
    • M
      char: use a fixed idx for child muxed chr · 949055a2
      Marc-André Lureau 提交于
      mux_chr_update_read_handler() is adding a new mux_cnt each time
      mux_chr_update_read_handler() is called, it's not possible to actually
      update the "child" chr callbacks that were set previously. This may lead
      to crashes if the "child" chr is destroyed:
      
      valgrind x86_64-softmmu/qemu-system-x86_64 -chardev
      stdio,mux=on,id=char0 -mon chardev=char0,mode=control,default
      
      when quitting:
      
      ==4306== Invalid read of size 8
      ==4306==    at 0x8061D3: json_lexer_destroy (json-lexer.c:385)
      ==4306==    by 0x7E39F8: json_message_parser_destroy (json-streamer.c:134)
      ==4306==    by 0x3447F6: monitor_qmp_event (monitor.c:3908)
      ==4306==    by 0x480153: mux_chr_send_event (qemu-char.c:630)
      ==4306==    by 0x480694: mux_chr_event (qemu-char.c:734)
      ==4306==    by 0x47F1E9: qemu_chr_be_event (qemu-char.c:205)
      ==4306==    by 0x481207: fd_chr_close (qemu-char.c:1114)
      ==4306==    by 0x481659: qemu_chr_close_stdio (qemu-char.c:1221)
      ==4306==    by 0x486F07: qemu_chr_free (qemu-char.c:4146)
      ==4306==    by 0x486F97: qemu_chr_delete (qemu-char.c:4154)
      ==4306==    by 0x487E66: qemu_chr_cleanup (qemu-char.c:4678)
      ==4306==    by 0x495A98: main (vl.c:4675)
      ==4306==  Address 0x28439e90 is 112 bytes inside a block of size 240 free'd
      ==4306==    at 0x4C2CD5A: free (vg_replace_malloc.c:530)
      ==4306==    by 0x1E4CBF2D: g_free (in /usr/lib64/libglib-2.0.so.0.4800.2)
      ==4306==    by 0x344DE9: monitor_cleanup (monitor.c:4058)
      ==4306==    by 0x495A93: main (vl.c:4674)
      ==4306==  Block was alloc'd at
      ==4306==    at 0x4C2BBAD: malloc (vg_replace_malloc.c:299)
      ==4306==    by 0x1E4CBE18: g_malloc (in /usr/lib64/libglib-2.0.so.0.4800.2)
      ==4306==    by 0x344BF8: monitor_init (monitor.c:4021)
      ==4306==    by 0x49063C: mon_init_func (vl.c:2417)
      ==4306==    by 0x7FC6DE: qemu_opts_foreach (qemu-option.c:1116)
      ==4306==    by 0x4954E0: main (vl.c:4473)
      
      Instead, keep the "child" chr associated with a particular idx so its
      handlers can be updated and removed to avoid the crash.
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <20161003094704.18087-3-marcandre.lureau@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      949055a2
  5. 27 9月, 2016 1 次提交
  6. 29 7月, 2016 1 次提交
  7. 13 7月, 2016 1 次提交
    • M
      char: do not use atexit cleanup handler · aa5cb7f5
      Marc-André Lureau 提交于
      It turns out qemu is calling exit() in various places from various
      threads without taking much care of resources state. The atexit()
      cleanup handlers cannot easily destroy resources that are in use (by
      the same thread or other).
      
      Since c1111a24, TCG arm guests run into the following abort() when
      running tests, the chardev mutex is locked during the write, so
      qemu_mutex_destroy() returns an error:
      
       #0  0x00007fffdbb806f5 in raise () at /lib64/libc.so.6
       #1  0x00007fffdbb822fa in abort () at /lib64/libc.so.6
       #2  0x00005555557616fe in error_exit (err=<optimized out>, msg=msg@entry=0x555555c38c30 <__func__.14622> "qemu_mutex_destroy")
           at /home/drjones/code/qemu/util/qemu-thread-posix.c:39
       #3  0x0000555555b0be20 in qemu_mutex_destroy (mutex=mutex@entry=0x5555566aa0e0) at /home/drjones/code/qemu/util/qemu-thread-posix.c:57
       #4  0x00005555558aab00 in qemu_chr_free_common (chr=0x5555566aa0e0) at /home/drjones/code/qemu/qemu-char.c:4029
       #5  0x00005555558b05f9 in qemu_chr_delete (chr=<optimized out>) at /home/drjones/code/qemu/qemu-char.c:4038
       #6  0x00005555558b05f9 in qemu_chr_delete (chr=<optimized out>) at /home/drjones/code/qemu/qemu-char.c:4044
       #7  0x00005555558b062c in qemu_chr_cleanup () at /home/drjones/code/qemu/qemu-char.c:4557
       #8  0x00007fffdbb851e8 in __run_exit_handlers () at /lib64/libc.so.6
       #9  0x00007fffdbb85235 in  () at /lib64/libc.so.6
       #10 0x00005555558d1b39 in testdev_write (testdev=0x5555566aa0a0) at /home/drjones/code/qemu/backends/testdev.c:71
       #11 0x00005555558d1b39 in testdev_write (chr=<optimized out>, buf=0x7fffc343fd9a "", len=0) at /home/drjones/code/qemu/backends/testdev.c:95
       #12 0x00005555558adced in qemu_chr_fe_write (s=0x5555566aa0e0, buf=buf@entry=0x7fffc343fd98 "0q", len=len@entry=2) at /home/drjones/code/qemu/qemu-char.c:282
      
      Instead of using a atexit() handler, only run the chardev cleanup as
      initially proposed at the end of main(), where there are less chances
      (hic) of conflicts or other races.
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Reported-by: NAndrew Jones <drjones@redhat.com>
      Message-Id: <20160704153823.16879-1-marcandre.lureau@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      aa5cb7f5
  8. 29 6月, 2016 1 次提交
  9. 17 6月, 2016 1 次提交
  10. 06 6月, 2016 1 次提交
  11. 23 3月, 2016 1 次提交
  12. 16 3月, 2016 1 次提交
    • P
      replay: character devices · 33577b47
      Pavel Dovgalyuk 提交于
      This patch implements record and replay of character devices.
      It records chardevs communication in replay mode. Recorded information
      include data read from backend and counter of bytes written
      from frontend to backend to preserve frontend internal state.
      If character device was configured through the command line in record mode,
      then in replay mode it should be also added to command line. Backend of
      the character device could be changed in replay mode.
      Replaying of devices that perform ioctl and get_msgfd operations is not
      supported.
      gdbstub which also acts as a backend is not recorded to allow controlling
      the replaying through gdb. Monitor backends are also not recorded.
      Signed-off-by: NPavel Dovgalyuk <pavel.dovgaluk@ispras.ru>
      Message-Id: <20160314074436.4980.83856.stgit@PASHA-ISP>
      [Add stubs. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      33577b47
  13. 25 2月, 2016 1 次提交
  14. 02 2月, 2016 1 次提交
  15. 16 1月, 2016 1 次提交
    • D
      qemu-char: add logfile facility to all chardev backends · d0d7708b
      Daniel P. Berrange 提交于
      Typically a UNIX guest OS will log boot messages to a serial
      port in addition to any graphical console. An admin user
      may also wish to use the serial port for an interactive
      console. A virtualization management system may wish to
      collect system boot messages by logging the serial port,
      but also wish to allow admins interactive access.
      
      Currently providing such a feature forces the mgmt app
      to either provide 2 separate serial ports, one for
      logging boot messages and one for interactive console
      login, or to proxy all output via a separate service
      that can multiplex the two needs onto one serial port.
      While both are valid approaches, they each have their
      own downsides. The former causes confusion and extra
      setup work for VM admins creating disk images. The latter
      places an extra burden to re-implement much of the QEMU
      chardev backends logic in libvirt or even higher level
      mgmt apps and adds extra hops in the data transfer path.
      
      A simpler approach that is satisfactory for many use
      cases is to allow the QEMU chardev backends to have a
      "logfile" property associated with them.
      
       $QEMU -chardev socket,host=localhost,port=9000,\
                      server=on,nowait,id-charserial0,\
      		logfile=/var/log/libvirt/qemu/test-serial0.log
             -device isa-serial,chardev=charserial0,id=serial0
      
      This patch introduces a 'ChardevCommon' struct which
      is setup as a base for all the ChardevBackend types.
      Ideally this would be registered directly as a base
      against ChardevBackend, rather than each type, but
      the QAPI generator doesn't allow that since the
      ChardevBackend is a non-discriminated union. The
      ChardevCommon struct provides the optional 'logfile'
      parameter, as well as 'logappend' which controls
      whether QEMU truncates or appends (default truncate).
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Message-Id: <1452516281-27519-1-git-send-email-berrange@redhat.com>
      [Call qemu_chr_parse_common if cd->parse is NULL. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      d0d7708b
  16. 25 10月, 2015 1 次提交
  17. 19 10月, 2015 4 次提交
  18. 14 10月, 2015 1 次提交
  19. 17 9月, 2014 2 次提交
  20. 06 8月, 2014 1 次提交
    • P
      backends: Introduce chr-testdev · 5692399f
      Paolo Bonzini 提交于
      From: Paolo Bonzini <pbonzini@redhat.com>
      
      chr-testdev enables a virtio serial channel to be used for guest
      initiated qemu exits. hw/misc/debugexit already enables guest
      initiated qemu exits, but only for PC targets. chr-testdev supports
      any virtio-capable target. kvm-unit-tests/arm is already making use
      of this backend.
      
      Currently there is a single command implemented, "q".  It takes a
      (prefix) argument for the exit code, thus an exit is implemented by
      writing, e.g. "1q", to the virtio-serial port.
      
      It can be used as:
         $QEMU ... \
           -device virtio-serial-device \
           -device virtserialport,chardev=ctd -chardev testdev,id=ctd
      
      or, use:
         $QEMU ... \
           -device virtio-serial-device \
           -device virtconsole,chardev=ctd -chardev testdev,id=ctd
      
      to bind it to virtio-serial port0.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NAndrew Jones <drjones@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5692399f
  21. 06 7月, 2014 1 次提交
    • K
      Handle G_IO_HUP in tcp_chr_read for tcp chardev · 812c1057
      Kirill Batuzov 提交于
      Since commit cdaa86a5
      ("Add G_IO_HUP handler for socket chardev")
      GLib limitation results in a bug on Windows host. Steps to reproduce:
      
      Start qemu: qemu-system-i386 -qmp tcp:127.0.0.1:4444:server:nowait
      Connect with telnet: telnet 127.0.0.1 4444
      Try sending some data from telnet.
      Expected result: answers from QEMU.
      Observed result: no answers (actually tcp_chr_read is not called at all).
      
      Due to GLib limitations it is not possible to create several watches on one
      channel on Windows hosts. See bug #338943 in GNOME bugzilla for details:
      https://bugzilla.gnome.org/show_bug.cgi?id=338943
      
      This reimplements commit cdaa86a5
      ("Add G_IO_HUP handler for socket chardev") using a single watch:
      
      Handle G_IO_HUP in tcp_chr_read instead. It is already watched by a
      corresponding watch.  Remove the second watch with its handler.
      
      Cc: Antonios Motakis <a.motakis@virtualopensystems.com>
      Cc: Nikolay Nikolaev <n.nikolaev@virtualopensystems.com>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NKirill Batuzov <batuzovk@ispras.ru>
      Signed-off-by: NNikita Belov <zodiac@ispras.ru>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      812c1057
  22. 23 6月, 2014 3 次提交
  23. 19 6月, 2014 4 次提交
  24. 11 6月, 2014 1 次提交
  25. 16 12月, 2013 1 次提交
  26. 05 9月, 2013 1 次提交
  27. 31 7月, 2013 1 次提交
    • M
      chardev: fix CHR_EVENT_OPENED events for mux chardevs · 7b7ab18d
      Michael Roth 提交于
      As of bd5c51ee, chardevs no longer use
      bottom-halves to issue CHR_EVENT_OPENED events. To maintain past
      semantics, we instead defer the CHR_EVENT_OPENED events toward the end
      of chardev initialization.
      
      For muxes, this isn't good enough, since a range of FEs must be able
      to attach to the mux prior to any CHR_EVENT_OPENED being issued, else
      each FE will immediately print it's initial output (prompts, banners,
      etc.) just prior to us switching to the next FE as part of
      initialization.
      
      The is new and confusing behavior for users, as they'll see output for
      things like the HMP monitor, even though their the current mux focus
      may be a guest serial port with potentially no output.
      
      We fix this by further deferring CHR_EVENT_OPENED events for FEs
      associated with muxes until after machine init by flagging mux chardevs
      with 'explicit_be_open', which suppresses emission of CHR_EVENT_OPENED
      events until we explicitly set the mux as opened later.
      
      Currently, we must defer till after machine init since we potentially
      associate FEs with muxes as part of realize (for instance,
      serial_isa_realizefn).
      Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      Message-id: 1375207462-8141-1-git-send-email-mdroth@linux.vnet.ibm.com
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
      7b7ab18d