From: Brice Waegeneire <brice@waegenei.re>
To: 34276@debbugs.gnu.org
Subject: bug#34276: ‘guix system disk-im age’ successfully builds a bad image
Date: Thu, 19 Mar 2020 20:05:08 +0000 [thread overview]
Message-ID: <7a36cb1fc7c68f5d63a324df49170cdc@waegenei.re> (raw)
In-Reply-To: <877eejfqmb.fsf@nckx>
Hello Ludovic,
> I investigated a bit. I managed to get our code to cause a kernel
> panic
> upon failure (patch below). However I fail to turn that guest kernel
> panic into a different QEMU exit code.
>
> I tried to use the “pvpanic” paravirtualized device (the ‘pvpanic.ko’
> module in the guest, and “-device pvpanic” on the QEMU command line),
> but unfortunately that thing is almost undocumented and I can’t get it
> to turn the panic into a non-zero exit code, nor do I know if it’s
> possible.
>
> Thoughts anyone?
I looked a little into it and I have found how to use pvpanic.
Unfortunately it's not as straight forward as getting a non-zero exit
code form qemu. When pvpanic is loaded in a VṂ, as you did with
“-device
pvpanic”, generate events[0] on the QMP interface when a crash happen
and qemu either shutdown or pause when using --no-shutdown[1].
(gnu build marionette) which use the “-monitor” interface could be
recycled to use “-qmp” a machine interface using JSON.
Following is log of a QMP session where the guest panicked[2]:
--8<---------------cut here---------------start------------->8---
{
"QMP": {
"version": {
"qemu": {
"micro": 0,
"minor": 2,
"major": 4
},
"package": ""
},
"capabilities": [
"oob"
]
}
}
{ "execute": "qmp_capabilities" }
{
"return": {
}
}
{
"timestamp": {
"seconds": 1584645026,
"microseconds": 936550
},
"event": "GUEST_PANICKED",
"data": {
"action": "pause"
}
}
{
"timestamp": {
"seconds": 1584645026,
"microseconds": 936675
},
"event": "GUEST_PANICKED",
"data": {
"action": "poweroff"
}
}
{
"timestamp": {
"seconds": 1584645026,
"microseconds": 936776
},
"event": "SHUTDOWN",
"data": {
"guest": true,
"reason": "guest-panic"
}
}
--8<---------------cut here---------------end--------------->8---
[0]:
https://github.com/qemu/qemu/blob/9ced5c7c20cb16dff0c2fa3242c3ee96b68cec2a/qapi/run-state.json#L339-L355
[1]:
https://github.com/qemu/qemu/blob/4dd6517e369828171290b65e11f6a45aeeed15af/softmmu/vl.c#L1423-L1427
[2]:
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/interop/qmp-intro.txt;hb=HEAD
Brice.
next prev parent reply other threads:[~2020-03-19 20:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-01 15:57 bug#34276: ‘guix system disk-image’ successfully builds a bad image Tobias Geerinckx-Rice
2019-03-17 12:09 ` Ludovic Courtès
2020-03-26 22:57 ` Ludovic Courtès
2020-03-19 20:05 ` Brice Waegeneire [this message]
2020-03-21 15:58 ` bug#34276: ‘guix system disk-im age’ " Ludovic Courtès
2020-03-21 16:44 ` Brice Waegeneire
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7a36cb1fc7c68f5d63a324df49170cdc@waegenei.re \
--to=brice@waegenei.re \
--cc=34276@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).