Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  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
  3. 22 6月, 2018 1 次提交
  5. 18 6月, 2018 1 次提交
  7. 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
  9. 01 6月, 2018 3 次提交
  11. 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
  13. 23 5月, 2018 1 次提交
  15. 20 5月, 2018 1 次提交
  17. 15 5月, 2018 4 次提交
  19. 09 5月, 2018 4 次提交
  21. 07 5月, 2018 1 次提交
  23. 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
  25. 27 4月, 2018 2 次提交
  27. 26 4月, 2018 4 次提交
  29. 28 3月, 2018 1 次提交
  31. 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
  33. 20 3月, 2018 3 次提交
  35. 14 3月, 2018 1 次提交
  37. 13 3月, 2018 1 次提交
  39. 12 3月, 2018 2 次提交
  41. 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
  43. 06 3月, 2018 3 次提交
反馈
建议 客服 返回
顶部