From: zhenwei pi <pizhenwei@bytedance.com>
To: pbonzini@redhat.com
Cc: Greg KH <gregkh@linuxfoundation.org>,
qemu-devel@nongnu.org, linux-kernel@vger.kernel.org,
"yelu@bytedance.com" <yelu@bytedance.com>
Subject: discuss about pvpanic
Date: Wed, 8 Jan 2020 16:25:52 +0800 [thread overview]
Message-ID: <2feff896-21fe-2bbe-6f68-9edfb476a110@bytedance.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
Hey, Paolo
Currently, pvpapic only supports bit 0(PVPANIC_PANICKED).
We usually expect that guest writes ioport (typical 0x505) in panic_notifier_list callback
during handling panic, then we can handle pvpapic event PVPANIC_PANICKED in QEMU.
On the other hand, guest wants to handle the crash by kdump-tools, and reboots without any
panic_notifier_list callback. So QEMU only knows that guest has rebooted (because guest
write 0xcf9 ioport for RCR request), but QEMU can't identify why guest resets.
In production environment, we hit about 100+ guest reboot event everyday, sadly we
can't separate the abnormal reboot from normal operation.
We want to add a new bit for pvpanic event(maybe PVPANIC_CRASHLOADED) to represent the guest has crashed,
and the panic is handled by the guest kernel. (here is the previous patchhttps://lkml.org/lkml/2019/12/14/265)
What do you think about this solution? Or do you have any other suggestions?
--
Thanks and Best Regards,
zhenwei pi
[-- Attachment #2: Type: text/html, Size: 1271 bytes --]
next reply other threads:[~2020-01-08 8:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-08 8:25 zhenwei pi [this message]
2020-01-08 9:36 ` discuss about pvpanic Paolo Bonzini
2020-01-08 9:58 ` Michal Privoznik
2020-01-08 10:05 ` Paolo Bonzini
2020-01-08 10:33 ` [External] " zhenwei pi
2020-01-08 12:14 ` Paolo Bonzini
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2feff896-21fe-2bbe-6f68-9edfb476a110@bytedance.com \
--to=pizhenwei@bytedance.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yelu@bytedance.com \
/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.
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 NNTP newsgroup(s).