On Mon, 14 Sep 2020 at 14:53, zhenwei pi <pizhenwei@bytedance.com> wrote:
Introduce 4 memory failure events for a guest. Then uplayer could
know when/why/what happened to a guest during hitting a hardware
memory failure.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
---
+##
+# @MemoryFailureAction:
+#
+# Host memory failure occurs, handled by QEMU.
+#
+# @hypervisor-ignore: action optional memory failure at QEMU process
+# addressspace (none PC-RAM), QEMU could ignore this
+# hardware memory failure.
+#
+# @hypervisor-stop: action required memory failure at QEMU process address
+# space (none PC-RAM), QEMU has to stop itself.
I'm not entirely clear what the descriptions here are trying to say.
These would be for memory failure events which are reported by the
host and which are not in guest RAM but are in the memory QEMU itself
is using ? ("PC-RAM" is a bit x86-specific.)
+#
+# @guest-mce: action required memory failure at PC-RAM, and guest enables MCE
+# handling, QEMU injects MCE to guest.
+#
+# @guest-triple-fault: action required memory failure at PC-RAM, but guest does
+# not enable MCE handling. QEMU raises triple fault and
+# shutdown/reset. Also see detailed info in QEMU log.
"triple fault" sounds rather x86-specific; other architectures
also have support for host memory failure notifications, so we
should design the QAPI events to have architecture-neutral
definitions and descriptions.
I think the four cases you're trying to distinguish here are:
(1) action-optional memory failure in memory used by the hypervisor
(which QEMU has ignored other than to report this event)
(2) action-required memory failure in memory used by the hypervisor
(QEMU is stopping)
(3) action-required memory failure in guest memory, which QEMU
has reported to the guest
(4) action-required memory failure in guest memory, but the
guest OS does not support a mechanism for reporting it
Is that right?
Anyway, I think we should try to find names for the failure
types that are not x86-specific.
thanks
-- PMM