Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 28 7月, 2015 1 次提交
  3. 09 7月, 2015 3 次提交
  5. 19 6月, 2015 1 次提交
  7. 28 5月, 2015 4 次提交
  9. 10 3月, 2015 1 次提交
  11. 11 12月, 2014 1 次提交
    • L
      Add the "-semihosting-config" option. · a38bb079
      由 Liviu Ionescu 提交于 
      The usual semihosting behaviour is to process the system calls locally and
return; unfortuantelly the initial implementation dinamically changed the
target to GDB during debug sessions, which, for the usual arm-none-eabi-gdb,
is not implemented. The result was that during debug sessions the semihosting
calls were discarded.

This patch adds a configuration variable and an option to set it on the
command line:

    -semihosting-config [enable=on|off,]target=native|gdb|auto

This option enables semihosting and defines where the semihosting calls will
be addressed, to QEMU ('native') or to GDB ('gdb'). The default is auto, which
means 'gdb' during debug sessions and 'native' otherwise.
Signed-off-by: NLiviu Ionescu <ilg@livius.net>
Message-id: 1416341957-9796-1-git-send-email-ilg@livius.net
[PMM: moved declaration and definition of semihosting_target to
 gdbstub.h and gdbstub.c to fix build failure on linux-user]
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      a38bb079
  13. 11 11月, 2014 1 次提交
  15. 06 10月, 2014 1 次提交
  17. 11 9月, 2014 1 次提交
  19. 14 3月, 2014 4 次提交
  21. 04 11月, 2013 1 次提交
    • P
      vl: allow "cont" from panicked state · df390768
      由 Paolo Bonzini 提交于 
      After reporting the GUEST_PANICKED monitor event, QEMU stops the VM.
The reason for this is that events are edge-triggered, and can be lost if
management dies at the wrong time.  Stopping a panicked VM lets management
know of a panic even if it has crashed; management can learn about the
panic when it restarts and queries running QEMU processes.  The downside
is of course that the VM will be paused while management is not running,
but that is acceptable if it only happens with explicit "-device pvpanic".

Upon learning of a panic, management (if configured to do so) can pick a
variety of behaviors: leave the VM paused, reset it, destroy it.  In
addition to all of these behaviors, it is possible to dump the VM core
from the host.

However, right now, the panicked state is irreversible, and can only be
exited by resetting the machine.  This means that any policy decision
is entirely in the hands of the host.  In particular there is no way to
use the "reboot on panic" option together with pvpanic.

This patch makes the panicked state reversible (and removes various
workarounds that were there because of the state being irreversible).
With this change, management has a wider set of possible policies: it
can just log the crash and leave policy to the guest, it can leave the
VM paused.  In particular, the "log the crash and continue" is implemented
simply by sending a "cont" as soon as management learns about the panic.
Management could also implement the "irreversible paused state" itself.
And again, all such actions can be coupled with dumping the VM core.

Unfortunately we cannot change the behavior of 1.6.0.  Thus, even if
it uses "-device pvpanic", management should check for "cont" failures.
If "cont" fails, management can then log that the VM remained paused
and urge the administrator to update QEMU.
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NLuiz Capitulino <lcapitulino@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      df390768
  23. 03 10月, 2013 1 次提交
  25. 03 9月, 2013 1 次提交
  27. 17 8月, 2013 1 次提交
  29. 27 7月, 2013 18 次提交