1. 26 6月, 2018 2 次提交
    • T
      hw/i386: Deprecate the machine types pc-0.10 and pc-0.11 · 08fe6824
      Thomas Huth 提交于
      The oldest machine type which is still used in a still maintained distro
      is a pc-0.12 based machine type in RHEL6, so everything that is older
      than pc-0.12 should not be used anymore. Thus let's deprecate pc-0.10
      and pc-0.11 so that we can finally remove them in a future release.
      Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: NThomas Huth <thuth@redhat.com>
      Message-Id: <1529917512-10528-1-git-send-email-thuth@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      08fe6824
    • I
      vl.c: do not allow --daemonize in combination with --preconfig CLI option · 2ee3518b
      Igor Mammedov 提交于
      some users when using --daemonize expect that QEMU will parse CLI options,
      initialize VM and only then complete daemonzation by signalling lead
      process to exit and start listening on monitor socket. So users treat
      parent process exit as sync point to connect to QEMU's monitor.
      
      That however doesn't work when --preconfig options is used, since it
      provides monitor before completing daemonization and expects user to
      issue exit-preconfig command when additional configuration via monitor
      is finished. We also can't move completing daemonization before
      preconfig monitor becomes available, since that would imply:
        * partially loosing ability to configure QEMU instance in --preconfig
          mode since QEMU might drop privileges, chroot and do other things
          when daemonization is completed
        * lead to loss of error messages in case they would happen after
          daemonization
      
      Be proactive now and make options mutually exclusive, so users would
      get clear error message instead of waiting for lead process exit
      indefinitely before connecting to monitor.
      
      PS:
      In case someone would come up with usecase where both options should
      be enabled at the same time we could drop this restriction as far
      as daemonization point is left where it is now (os_setup_post).
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Message-Id: <1529501059-163139-1-git-send-email-imammedo@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      2ee3518b
  2. 22 6月, 2018 1 次提交
  3. 18 6月, 2018 1 次提交
  4. 12 6月, 2018 1 次提交
    • I
      cli: Don't run early event loop if no --preconfig was specified · 0f5319ea
      Igor Mammedov 提交于
      After 047f7038 it is possible for event loop to run two
      times. First time whilst parsing command line options (the idea
      is to bring up monitor early so that management applications can
      tweak config before machine is initialized). And the second time
      is after everything is set up (this is the usual place). In both
      cases the event loop is called as main_loop_wait(nonblocking =
      false) which causes the event loop to block until at least one
      event occurred.
      
      Now, consider that somebody (i.e. libvirt) calls us with
      -daemonize. This operation is split in two steps. The main()
      calls os_daemonize() which fork()-s and then waits in read()
      until child notifies it via write():
      
      /qemu.git $ ./x86_64-softmmu/qemu-system-x86_64 -S -daemonize \
        -no-user-config -nodefaults -nographic
      
        main():                child:
          os_daemonize():
            read(pipe[0])
      
                                 main_loop():
                                   main_loop_wait(false)
      
                                 os_setup_post():
                                   write(pipe[1])
      
                                 main_loop():
                                   main_loop_wait(false)
      
      Here it can be clearly seen that main() does not exit until an
      event occurs, but at the same time nobody will touch the monitor
      socket until their exec("qemu-system-*") finishes. So the whole
      thing deadlocks.
      
      The solution is to not call main_loop_wait() unless --preconfig was
      specified (in which case caller knows they must connect to the
      socket before exec() finishes).
      
      Patch also fixes hang when -nodefaults option is used, which were
      causing QEMU hang in the early main_loop_wait() indefinitely by
      the same means (not calling main_loop_wait() unless --preconfig
      is present on CLI)
      
      Based on
        From: Michal Privoznik <mprivozn@redhat.com>
        Subject: [PATCH] cli: Don't run early event loop if no --preconfig was specified
        Message-Id: <ad910973c593c5ac2fed3a10ea958f7e9c12f82c.1527935663.git.mprivozn@redhat.com>
      Fixes: 047f7038Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Message-Id: <1528207243-268226-2-git-send-email-imammedo@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      0f5319ea
  5. 01 6月, 2018 3 次提交
  6. 31 5月, 2018 1 次提交
    • I
      cli: add --preconfig option · 047f7038
      Igor Mammedov 提交于
      This option allows pausing QEMU in the new RUN_STATE_PRECONFIG state,
      allowing the configuration of QEMU from QMP before the machine jumps
      into board initialization code of machine_run_board_init()
      
      The intent is to allow management to query machine state and additionally
      configure it using previous query results within one QEMU instance
      (i.e. eliminate the need to start QEMU twice, 1st to query board specific
      parameters and 2nd for actual VM start using query results for
      additional parameters).
      
      The new option complements -S option and could be used with or without
      it. The difference is that -S pauses QEMU when the machine is completely
      initialized with all devices wired up and ready to execute guest code
      (QEMU needs only to unpause VCPUs to let guest execute its code),
      while the "preconfig" option pauses QEMU early before board specific init
      callback (machine_run_board_init) is executed and allows the configuration
      of machine parameters which will be used by board init code.
      
      When early introspection/configuration is done, command 'exit-preconfig'
      should be used to exit RUN_STATE_PRECONFIG and transition to the next
      requested state (i.e. if -S is used then QEMU will pause the second
      time when board/device initialization is completed or start guest
      execution if -S isn't provided on CLI)
      
      PS:
      Initially 'preconfig' is planned to be used for configuring numa
      topology depending on board specified possible cpus layout.
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1526059483-42847-1-git-send-email-imammedo@redhat.com>
      [ehabkost: Changed "since 2.13" to "since 3.0"]
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      047f7038
  7. 23 5月, 2018 1 次提交
  8. 20 5月, 2018 1 次提交
  9. 15 5月, 2018 4 次提交
  10. 09 5月, 2018 4 次提交
  11. 07 5月, 2018 1 次提交
  12. 30 4月, 2018 1 次提交
    • T
      hw/s390x: Allow to configure the consoles with the "-serial" parameter · 052888f0
      Thomas Huth 提交于
      The consoles ("sclpconsole" and "sclplmconsole") can only be configured
      with "-device" and "-chardev" so far. Other machines use the convenience
      option "-serial" to configure the default consoles, even for virtual
      consoles like spapr-vty on the pseries machine. So let's support this
      option on s390x, too. This way we can easily enable the serial console
      here again with "-nodefaults", for example:
      
      qemu-system-s390x -no-shutdown -nographic -nodefaults -serial mon:stdio
      
      ... which is way shorter than typing:
      
      qemu-system-s390x -no-shutdown -nographic -nodefaults \
        -chardev stdio,id=c1,mux=on -device sclpconsole,chardev=c1 \
        -mon chardev=c1
      
      The -serial parameter can also be used if you only want to see the QEMU
      monitor on stdio without using -nodefaults, but not the console output.
      That's something that is pretty impossible with the current code today:
      
      qemu-system-s390x -no-shutdown -nographic -serial none
      
      While we're at it, this patch also maps the second -serial option to the
      "sclplmconsole", so that there is now an easy way to configure this second
      console on s390x, too, for example:
      
      qemu-system-s390x -no-shutdown -nographic -serial null -serial mon:stdio
      
      Additionally, the new code is also smaller than the old one and we have
      less s390x-specific code in vl.c :-)
      
      I've also checked that migration still works as expected by migrating
      a guest with console output back and forth between a qemu-system-s390x
      that has this patch and an instance without this patch.
      Signed-off-by: NThomas Huth <thuth@redhat.com>
      Message-Id: <1524754794-28005-1-git-send-email-thuth@redhat.com>
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      052888f0
  13. 27 4月, 2018 2 次提交
  14. 26 4月, 2018 4 次提交
  15. 28 3月, 2018 1 次提交
  16. 27 3月, 2018 1 次提交
    • P
      monitor: new parameter "x-oob" · be933ffc
      Peter Xu 提交于
      Add new parameter to optionally enable Out-Of-Band for a QMP server.
      
      An example command line:
      
        ./qemu-system-x86_64 -chardev stdio,id=char0 \
                             -mon chardev=char0,mode=control,x-oob=on
      
      By default, Out-Of-Band is off.
      
      It is not allowed if either MUX or non-QMP is detected, since
      Out-Of-Band is currently only for QMP, and non-MUX chardev backends.
      
      Note that the client STILL has to request 'oob' during qmp_capabilities;
      in part because the x-oob command line option may disappear in the
      future if we decide the capabilities negotiation is sufficient.
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Message-Id: <20180326063901.27425-4-peterx@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      [eblake: enhance commit message]
      Tested-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      be933ffc
  17. 20 3月, 2018 3 次提交
  18. 14 3月, 2018 1 次提交
  19. 13 3月, 2018 1 次提交
  20. 12 3月, 2018 2 次提交
  21. 09 3月, 2018 1 次提交
    • S
      vl: introduce vm_shutdown() · 4486e89c
      Stefan Hajnoczi 提交于
      Commit 00d09fdb ("vl: pause vcpus before
      stopping iothreads") and commit dce8921b
      ("iothread: Stop threads before main() quits") tried to work around the
      fact that emulation was still active during termination by stopping
      iothreads.  They suffer from race conditions:
      1. virtio_scsi_handle_cmd_vq() racing with iothread_stop_all() hits the
         virtio_scsi_ctx_check() assertion failure because the BDS AioContext
         has been modified by iothread_stop_all().
      2. Guest vq kick racing with main loop termination leaves a readable
         ioeventfd that is handled by the next aio_poll() when external
         clients are enabled again, resulting in unwanted emulation activity.
      
      This patch obsoletes those commits by fully disabling emulation activity
      when vcpus are stopped.
      
      Use the new vm_shutdown() function instead of pause_all_vcpus() so that
      vm change state handlers are invoked too.  Virtio devices will now stop
      their ioeventfds, preventing further emulation activity after vm_stop().
      
      Note that vm_stop(RUN_STATE_SHUTDOWN) cannot be used because it emits a
      QMP STOP event that may affect existing clients.
      
      It is no longer necessary to call replay_disable_events() directly since
      vm_shutdown() does so already.
      
      Drop iothread_stop_all() since it is no longer used.
      
      Cc: Fam Zheng <famz@redhat.com>
      Cc: Kevin Wolf <kwolf@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: NFam Zheng <famz@redhat.com>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      Message-id: 20180307144205.20619-5-stefanha@redhat.com
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      4486e89c
  22. 06 3月, 2018 3 次提交
新手
引导
客服 返回
顶部