[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH v2 0/3] add MEMORY_FAILURE event
From: |
zhenwei pi |
Subject: |
[PATCH v2 0/3] add MEMORY_FAILURE event |
Date: |
Tue, 22 Sep 2020 17:56:27 +0800 |
v1->v2:
Suggested by Peter Maydell, rename events to make them
architecture-neutral:
'PC-RAM' -> 'guest-memory'
'guest-triple-fault' -> 'guest-mce-fatal'
Suggested by Paolo, add more fields in event:
'action-required': boolean type to distinguish a guest-mce is AR/AO.
'recursive': boolean type. set true if: previous MCE in processing
in guest, another AO MCE occurs.
v1:
Although QEMU could catch signal BUS to handle hardware memory
corrupted event, sadly, QEMU just prints a little log and try to fix
it silently.
In these patches, introduce a 'MEMORY_FAILURE' event with 4 detailed
actions of QEMU, then uplayer could know what situaction QEMU hit and
did. And further step we can do: if a host server hits a 'hypervisor-ignore'
or 'guest-mce', scheduler could migrate VM to another host; if hitting
'hypervisor-stop' or 'guest-triple-fault', scheduler could select other
healthy servers to launch VM.
Zhenwei Pi (3):
target-i386: seperate MCIP & MCE_MASK error reason
qapi/run-state.json: introduce memory failure event
target-i386: post memory failure event to uplayer
qapi/run-state.json | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++
target/i386/helper.c | 40 +++++++++++++++++++++++++------
target/i386/kvm.c | 7 +++++-
3 files changed, 106 insertions(+), 8 deletions(-)
--
2.11.0
- [PATCH v2 0/3] add MEMORY_FAILURE event,
zhenwei pi <=
- [PATCH v2 1/3] target-i386: seperate MCIP & MCE_MASK error reason, zhenwei pi, 2020/09/22
- [PATCH v2 2/3] qapi/run-state.json: introduce memory failure event, zhenwei pi, 2020/09/22
- [PATCH v2 3/3] target-i386: post memory failure event to uplayer, zhenwei pi, 2020/09/22
- Re: [PATCH v2 0/3] add MEMORY_FAILURE event, no-reply, 2020/09/22
- PING: [PATCH v2 0/3] add MEMORY_FAILURE event, zhenwei pi, 2020/09/28