arch/s390/include/asm/kvm_host_types.h | 1 + arch/s390/kvm/interrupt.c | 3 ++ arch/s390/kvm/kvm-s390.c | 72 ++++++++++++++++++++++---- arch/s390/kvm/kvm-s390.h | 6 +++ arch/s390/kvm/sigp.c | 8 ++- 5 files changed, 77 insertions(+), 13 deletions(-)
Add support for KVM_MP_STATE_CHECK_STOP to enable proper VM migration
and error handling for s390 guests. The CHECK_STOP state represents a
CPU that encountered a severe machine check and is halted in an error
state.
This implementation adds:
- CPUSTAT_CHECK_STOP flag to track check-stopped CPUs
- is_vcpu_check_stopped() helper macro for state checking
- kvm_s390_vcpu_check_stop() function to transition CPUs to CHECK_STOP
- Integration with Protected VM Ultravisor (PV_CPU_STATE_CHKSTP)
- Interrupt blocking for check-stopped CPUs in deliverable_irqs()
- Recovery path enabling CHECK_STOP -> OPERATING transitions
- Proper state precedence where CHECK_STOP takes priority over STOPPED
Signed-off-by: Josephine Pfeiffer <hi@josie.lol>
---
arch/s390/include/asm/kvm_host_types.h | 1 +
arch/s390/kvm/interrupt.c | 3 ++
arch/s390/kvm/kvm-s390.c | 72 ++++++++++++++++++++++----
arch/s390/kvm/kvm-s390.h | 6 +++
arch/s390/kvm/sigp.c | 8 ++-
5 files changed, 77 insertions(+), 13 deletions(-)
diff --git a/arch/s390/include/asm/kvm_host_types.h b/arch/s390/include/asm/kvm_host_types.h
index 1394d3fb648f..a86e326a2eee 100644
--- a/arch/s390/include/asm/kvm_host_types.h
+++ b/arch/s390/include/asm/kvm_host_types.h
@@ -111,6 +111,7 @@ struct mcck_volatile_info {
((((sie_block)->sidad & SIDAD_SIZE_MASK) + 1) * PAGE_SIZE)
#define CPUSTAT_STOPPED 0x80000000
+#define CPUSTAT_CHECK_STOP 0x40000000
#define CPUSTAT_WAIT 0x10000000
#define CPUSTAT_ECALL_PEND 0x08000000
#define CPUSTAT_STOP_INT 0x04000000
diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
index c62a868cf2b6..e09e5aff318a 100644
--- a/arch/s390/kvm/interrupt.c
+++ b/arch/s390/kvm/interrupt.c
@@ -361,6 +361,9 @@ static unsigned long deliverable_irqs(struct kvm_vcpu *vcpu)
if (!active_mask)
return 0;
+ if (kvm_s390_test_cpuflags(vcpu, CPUSTAT_CHECK_STOP))
+ return 0;
+
if (psw_extint_disabled(vcpu))
active_mask &= ~IRQ_PEND_EXT_MASK;
if (psw_ioint_disabled(vcpu))
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 16ba04062854..25eb3bebdfea 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -4465,16 +4465,17 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
struct kvm_mp_state *mp_state)
{
- int ret;
-
vcpu_load(vcpu);
- /* CHECK_STOP and LOAD are not supported yet */
- ret = is_vcpu_stopped(vcpu) ? KVM_MP_STATE_STOPPED :
- KVM_MP_STATE_OPERATING;
+ if (is_vcpu_check_stopped(vcpu))
+ mp_state->mp_state = KVM_MP_STATE_CHECK_STOP;
+ else if (is_vcpu_stopped(vcpu))
+ mp_state->mp_state = KVM_MP_STATE_STOPPED;
+ else
+ mp_state->mp_state = KVM_MP_STATE_OPERATING;
vcpu_put(vcpu);
- return ret;
+ return 0;
}
int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
@@ -4502,7 +4503,8 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
rc = kvm_s390_pv_set_cpu_state(vcpu, PV_CPU_STATE_OPR_LOAD);
break;
case KVM_MP_STATE_CHECK_STOP:
- fallthrough; /* CHECK_STOP and LOAD are not supported yet */
+ rc = kvm_s390_vcpu_check_stop(vcpu);
+ break;
default:
rc = -ENXIO;
}
@@ -5488,7 +5490,7 @@ int kvm_s390_vcpu_start(struct kvm_vcpu *vcpu)
{
int i, online_vcpus, r = 0, started_vcpus = 0;
- if (!is_vcpu_stopped(vcpu))
+ if (!is_vcpu_stopped(vcpu) && !is_vcpu_check_stopped(vcpu))
return 0;
trace_kvm_s390_vcpu_start_stop(vcpu->vcpu_id, 1);
@@ -5506,7 +5508,9 @@ int kvm_s390_vcpu_start(struct kvm_vcpu *vcpu)
}
for (i = 0; i < online_vcpus; i++) {
- if (!is_vcpu_stopped(kvm_get_vcpu(vcpu->kvm, i)))
+ struct kvm_vcpu *tmp = kvm_get_vcpu(vcpu->kvm, i);
+
+ if (!is_vcpu_stopped(tmp) && !is_vcpu_check_stopped(tmp))
started_vcpus++;
}
@@ -5522,7 +5526,7 @@ int kvm_s390_vcpu_start(struct kvm_vcpu *vcpu)
__disable_ibs_on_all_vcpus(vcpu->kvm);
}
- kvm_s390_clear_cpuflags(vcpu, CPUSTAT_STOPPED);
+ kvm_s390_clear_cpuflags(vcpu, CPUSTAT_STOPPED | CPUSTAT_CHECK_STOP);
/*
* The real PSW might have changed due to a RESTART interpreted by the
* ultravisor. We block all interrupts and let the next sie exit
@@ -5566,7 +5570,11 @@ int kvm_s390_vcpu_stop(struct kvm_vcpu *vcpu)
* now that the SIGP STOP and SIGP STOP AND STORE STATUS orders
* have been fully processed. This will ensure that the VCPU
* is kept BUSY if another VCPU is inquiring with SIGP SENSE.
+ *
+ * Clear CHECK_STOP before setting STOPPED to handle the state
+ * transition CHECK_STOP -> STOPPED.
*/
+ kvm_s390_clear_cpuflags(vcpu, CPUSTAT_CHECK_STOP);
kvm_s390_set_cpuflags(vcpu, CPUSTAT_STOPPED);
kvm_s390_clear_stop_irq(vcpu);
@@ -5575,7 +5583,7 @@ int kvm_s390_vcpu_stop(struct kvm_vcpu *vcpu)
for (i = 0; i < online_vcpus; i++) {
struct kvm_vcpu *tmp = kvm_get_vcpu(vcpu->kvm, i);
- if (!is_vcpu_stopped(tmp)) {
+ if (!is_vcpu_stopped(tmp) && !is_vcpu_check_stopped(tmp)) {
started_vcpus++;
started_vcpu = tmp;
}
@@ -5593,6 +5601,48 @@ int kvm_s390_vcpu_stop(struct kvm_vcpu *vcpu)
return 0;
}
+int kvm_s390_vcpu_check_stop(struct kvm_vcpu *vcpu)
+{
+ int r = 0;
+
+ /* trace: 0=stop, 1=start, 2=check-stop */
+ trace_kvm_s390_vcpu_start_stop(vcpu->vcpu_id, 2);
+ /* Only one cpu at a time may enter/leave the STOPPED/CHECK_STOP state. */
+ spin_lock(&vcpu->kvm->arch.start_stop_lock);
+
+ if (kvm_s390_test_cpuflags(vcpu, CPUSTAT_CHECK_STOP)) {
+ __disable_ibs_on_vcpu(vcpu);
+ goto out;
+ }
+
+ if (kvm_s390_pv_cpu_is_protected(vcpu)) {
+ r = kvm_s390_pv_set_cpu_state(vcpu, PV_CPU_STATE_CHKSTP);
+ if (r) {
+ spin_unlock(&vcpu->kvm->arch.start_stop_lock);
+ return r;
+ }
+ }
+
+ /*
+ * Clear STOPPED if it was set, CHECK_STOP takes precedence.
+ * This allows the transition STOPPED -> CHECK_STOP.
+ * The reverse transition CHECK_STOP -> STOPPED is handled by
+ * kvm_s390_vcpu_stop() which clears CHECK_STOP before setting STOPPED.
+ */
+ if (kvm_s390_test_cpuflags(vcpu, CPUSTAT_STOPPED))
+ kvm_s390_clear_cpuflags(vcpu, CPUSTAT_STOPPED);
+
+ kvm_s390_set_cpuflags(vcpu, CPUSTAT_CHECK_STOP);
+ kvm_s390_clear_stop_irq(vcpu);
+ __disable_ibs_on_vcpu(vcpu);
+
+out:
+ spin_unlock(&vcpu->kvm->arch.start_stop_lock);
+ return r;
+}
+
static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
struct kvm_enable_cap *cap)
{
diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
index c44fe0c3a097..6851f52bdddb 100644
--- a/arch/s390/kvm/kvm-s390.h
+++ b/arch/s390/kvm/kvm-s390.h
@@ -98,6 +98,11 @@ static inline int is_vcpu_stopped(struct kvm_vcpu *vcpu)
return kvm_s390_test_cpuflags(vcpu, CPUSTAT_STOPPED);
}
+static inline int is_vcpu_check_stopped(struct kvm_vcpu *vcpu)
+{
+ return kvm_s390_test_cpuflags(vcpu, CPUSTAT_CHECK_STOP);
+}
+
static inline int is_vcpu_idle(struct kvm_vcpu *vcpu)
{
return test_bit(vcpu->vcpu_idx, vcpu->kvm->arch.idle_mask);
@@ -451,6 +456,7 @@ int kvm_s390_store_status_unloaded(struct kvm_vcpu *vcpu, unsigned long addr);
int kvm_s390_vcpu_store_status(struct kvm_vcpu *vcpu, unsigned long addr);
int kvm_s390_vcpu_start(struct kvm_vcpu *vcpu);
int kvm_s390_vcpu_stop(struct kvm_vcpu *vcpu);
+int kvm_s390_vcpu_check_stop(struct kvm_vcpu *vcpu);
void kvm_s390_vcpu_block(struct kvm_vcpu *vcpu);
void kvm_s390_vcpu_unblock(struct kvm_vcpu *vcpu);
bool kvm_s390_vcpu_sie_inhibited(struct kvm_vcpu *vcpu);
diff --git a/arch/s390/kvm/sigp.c b/arch/s390/kvm/sigp.c
index 55c34cb35428..03f1084f63cf 100644
--- a/arch/s390/kvm/sigp.c
+++ b/arch/s390/kvm/sigp.c
@@ -21,16 +21,19 @@ static int __sigp_sense(struct kvm_vcpu *vcpu, struct kvm_vcpu *dst_vcpu,
u64 *reg)
{
const bool stopped = kvm_s390_test_cpuflags(dst_vcpu, CPUSTAT_STOPPED);
+ const bool check_stopped = kvm_s390_test_cpuflags(dst_vcpu, CPUSTAT_CHECK_STOP);
int rc;
int ext_call_pending;
ext_call_pending = kvm_s390_ext_call_pending(dst_vcpu);
- if (!stopped && !ext_call_pending)
+ if (!stopped && !check_stopped && !ext_call_pending)
rc = SIGP_CC_ORDER_CODE_ACCEPTED;
else {
*reg &= 0xffffffff00000000UL;
if (ext_call_pending)
*reg |= SIGP_STATUS_EXT_CALL_PENDING;
+ if (check_stopped)
+ *reg |= SIGP_STATUS_CHECK_STOP;
if (stopped)
*reg |= SIGP_STATUS_STOPPED;
rc = SIGP_CC_STATUS_STORED;
@@ -221,7 +224,8 @@ static int __sigp_sense_running(struct kvm_vcpu *vcpu,
return SIGP_CC_STATUS_STORED;
}
- if (kvm_s390_test_cpuflags(dst_vcpu, CPUSTAT_RUNNING)) {
+ if (kvm_s390_test_cpuflags(dst_vcpu, CPUSTAT_RUNNING) &&
+ !kvm_s390_test_cpuflags(dst_vcpu, CPUSTAT_CHECK_STOP)) {
/* running */
rc = SIGP_CC_ORDER_CODE_ACCEPTED;
} else {
--
2.51.2Am 17.11.25 um 16:18 schrieb Josephine Pfeiffer:
> Add support for KVM_MP_STATE_CHECK_STOP to enable proper VM migration
> and error handling for s390 guests. The CHECK_STOP state represents a
> CPU that encountered a severe machine check and is halted in an error
> state.
I think the patch description is misleading. We do have proper VM
migration and we also have error handling in the kvm module. The host
machine check handler will forward guest machine checks to the guest.
This logic is certainly not perfect but kind of good enough for most
cases.
Now: The architecture defines that state and the interface is certainly
there. So implementing it will allow userspace to put a CPU into checkstop
state if you ever need that. We also have a checkstop state that you
can put a secure CPU in.
The usecase is dubious though. The only case of the options from POP
chapter11 that makes sense to me in a virtualized environment is an exigent
machine check but a problem to actually deliver that (multiple reasons,
like the OS has machine checks disabled in PSW, or the prefix register
is broken).
So I am curious, do you have any specific usecase in mind?
I assume you have a related QEMU patch somewhere?
>
> This implementation adds:
> - CPUSTAT_CHECK_STOP flag to track check-stopped CPUs
> - is_vcpu_check_stopped() helper macro for state checking
> - kvm_s390_vcpu_check_stop() function to transition CPUs to CHECK_STOP
> - Integration with Protected VM Ultravisor (PV_CPU_STATE_CHKSTP)
> - Interrupt blocking for check-stopped CPUs in deliverable_irqs()
> - Recovery path enabling CHECK_STOP -> OPERATING transitions
> - Proper state precedence where CHECK_STOP takes priority over STOPPED
>
> Signed-off-by: Josephine Pfeiffer <hi@josie.lol>
> ---
> arch/s390/include/asm/kvm_host_types.h | 1 +
> arch/s390/kvm/interrupt.c | 3 ++
> arch/s390/kvm/kvm-s390.c | 72 ++++++++++++++++++++++----
> arch/s390/kvm/kvm-s390.h | 6 +++
> arch/s390/kvm/sigp.c | 8 ++-
> 5 files changed, 77 insertions(+), 13 deletions(-)
>
From a quick glance the patch in general does not look wrong but at least this is wrong:> diff --git a/arch/s390/include/asm/kvm_host_types.h b/arch/s390/include/asm/kvm_host_types.h
> index 1394d3fb648f..a86e326a2eee 100644
> --- a/arch/s390/include/asm/kvm_host_types.h
> +++ b/arch/s390/include/asm/kvm_host_types.h
> @@ -111,6 +111,7 @@ struct mcck_volatile_info {
> ((((sie_block)->sidad & SIDAD_SIZE_MASK) + 1) * PAGE_SIZE)
>
> #define CPUSTAT_STOPPED 0x80000000
> +#define CPUSTAT_CHECK_STOP 0x40000000
Bit 1 of the sie control block is a hardware defined bit and
its meaning is not checkstop, so this is not the right way to do it.
Lets first clarify your usecase so that we can see what the right way forward is.
Christian
On Mon, 17 Nov 2025 19:14:57 +0100, Christian Borntraeger wrote:
> Am 17.11.25 um 16:18 schrieb Josephine Pfeiffer:
> > Add support for KVM_MP_STATE_CHECK_STOP to enable proper VM migration
> > and error handling for s390 guests. The CHECK_STOP state represents a
> > CPU that encountered a severe machine check and is halted in an error
> > state.
>
> I think the patch description is misleading. We do have proper VM
> migration and we also have error handling in the kvm module. The host
> machine check handler will forward guest machine checks to the guest.
> This logic is certainly not perfect but kind of good enough for most
> cases.
First of all, thank you for taking the time to look at my patch, and sorry
for taking so long to write up the reply.
You're right, QEMU migrates cpu_state via vmstate [1] and only uses
KVM_SET_MP_STATE to restore the state after migration [2], never calling
KVM_GET_MP_STATE. So I misunderstood something there.
What prompted me to look into this was that the KVM API has advertised
CHECK_STOP support without implementing it.
Looking at commit 6352e4d2dd9a [3] from 2014: "KVM: s390: implement
KVM_(S|G)ET_MP_STATE for user space state control"
This commit added KVM_MP_STATE_CHECK_STOP to include/uapi/linux/kvm.h [4] and
documented it in Documentation/virtual/kvm/api.txt with:
"KVM_MP_STATE_CHECK_STOP: the vcpu is in a special error state [s390]"
But the implementation was explicitly deferred with a fallthrough comment [3]:
case KVM_MP_STATE_LOAD:
case KVM_MP_STATE_CHECK_STOP:
/* fall through - CHECK_STOP and LOAD are not supported yet */
default:
rc = -ENXIO;
This created a bit of an API asymmetry where:
- Documentation/virt/kvm/api.rst:1546 [5] advertises CHECK_STOP as valid
- KVM_SET_MP_STATE rejects it with -ENXIO
- KVM_GET_MP_STATE never returns it (always returns STOPPED or OPERATING) [6]
> Now: The architecture defines that state and the interface is certainly
> there. So implementing it will allow userspace to put a CPU into checkstop
> state if you ever need that. We also have a checkstop state that you
> can put a secure CPU in.
>
> The usecase is dubious though. The only case of the options from POP
> chapter11 that makes sense to me in a virtualized environment is an exigent
> machine check but a problem to actually deliver that (multiple reasons,
> like the OS has machine checks disabled in PSW, or the prefix register
> is broken).
>
> So I am curious, do you have any specific usecase in mind?
> I assume you have a related QEMU patch somewhere?
The use cases I see are:
1. API completeness: The state was added to the UAPI 11 years ago but never
implemented. Userspace cannot use a documented API feature.
2. Fault injection testing: Administrators testing failover/monitoring for
hardware failures could programmatically put a CPU into CHECK_STOP to
verify their procedures work.
3. Protected Virtualization: The patch adds PV_CPU_STATE_CHKSTP support [7]
for the Ultravisor, which can put secure CPUs into CHECK_STOP. Without this,
userspace cannot detect/handle that condition.
I don't have a QEMU patch, since QEMU already handles the state internally
via cpu_state [1] and only needs KVM_SET_MP_STATE to work (which this enables).
> From a quick glance the patch in general does not look wrong but at
> least this is wrong:
> > diff --git a/arch/s390/include/asm/kvm_host_types.h b/arch/s390/include/asm/kvm_host_types.h
> > index 1394d3fb648f..a86e326a2eee 100644
> > --- a/arch/s390/include/asm/kvm_host_types.h
> > +++ b/arch/s390/include/asm/kvm_host_types.h
> > @@ -111,6 +111,7 @@ struct mcck_volatile_info {
> > ((((sie_block)->sidad & SIDAD_SIZE_MASK) + 1) * PAGE_SIZE)
> >
> > #define CPUSTAT_STOPPED 0x80000000
> > +#define CPUSTAT_CHECK_STOP 0x40000000
> Bit 1 of the sie control block is a hardware defined bit and
> its meaning is not checkstop, so this is not the right way to do it.
> Lets first clarify your usecase so that we can see what the right way
> forward is.
Understood - using bit 1 of the hardware SIE control block is wrong.
I guess the correct approach would be to add a software-only flag to track CHECK_STOP
state. Unlike STOPPED (which uses CPUSTAT_STOPPED [8]), CHECK_STOP would need software
tracking since there isn't a corresponding hardware bit with the correct meaning.
Would adding a field to struct kvm_vcpu_arch [9] be the right approach? Or is
there a better way to track this state that I'm missing?
I think completing the API makes sense, even if the use case is uncommon.
Thanks,
Josephine
References:
[1] https://github.com/qemu/qemu/blob/master/target/s390x/machine.c#L270
VMSTATE_UINT8(env.cpu_state, S390CPU)
[2] https://github.com/qemu/qemu/blob/master/target/s390x/kvm/kvm.c#L410
kvm_arch_init_vcpu() -> kvm_s390_set_cpu_state()
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6352e4d2dd9a
KVM: s390: implement KVM_(S|G)ET_MP_STATE for user space state control
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/kvm.h#n596
#define KVM_MP_STATE_CHECK_STOP 6
[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/virt/kvm/api.rst#n1546
KVM_MP_STATE_CHECK_STOP the vcpu is in a special error state [s390]
[6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/kvm/kvm-s390.c#n4465
kvm_arch_vcpu_ioctl_get_mpstate() implementation
[7] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/include/asm/uv.h#n252
#define PV_CPU_STATE_CHKSTP 3
[8] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/include/asm/kvm_host_types.h#n113
#define CPUSTAT_STOPPED 0x80000000 (bit 0 of SIE control block cpuflags)
[9] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/include/asm/kvm_host.h#n414
struct kvm_vcpu_arch
On 11/20/25 19:28, Josephine Pfeiffer wrote: > On Mon, 17 Nov 2025 19:14:57 +0100, Christian Borntraeger wrote: >> Am 17.11.25 um 16:18 schrieb Josephine Pfeiffer: >>> Add support for KVM_MP_STATE_CHECK_STOP to enable proper VM migration >>> and error handling for s390 guests. The CHECK_STOP state represents a >>> CPU that encountered a severe machine check and is halted in an error >>> state. >> >> I think the patch description is misleading. We do have proper VM >> migration and we also have error handling in the kvm module. The host >> machine check handler will forward guest machine checks to the guest. >> This logic is certainly not perfect but kind of good enough for most >> cases. > > First of all, thank you for taking the time to look at my patch, and sorry > for taking so long to write up the reply. > > You're right, QEMU migrates cpu_state via vmstate [1] and only uses > KVM_SET_MP_STATE to restore the state after migration [2], never calling > KVM_GET_MP_STATE. So I misunderstood something there. > > What prompted me to look into this was that the KVM API has advertised > CHECK_STOP support without implementing it. > Looking at commit 6352e4d2dd9a [3] from 2014: "KVM: s390: implement > KVM_(S|G)ET_MP_STATE for user space state control" > > This commit added KVM_MP_STATE_CHECK_STOP to include/uapi/linux/kvm.h [4] and > documented it in Documentation/virtual/kvm/api.txt with: > > "KVM_MP_STATE_CHECK_STOP: the vcpu is in a special error state [s390]" > > But the implementation was explicitly deferred with a fallthrough comment [3]: > > case KVM_MP_STATE_LOAD: > case KVM_MP_STATE_CHECK_STOP: > /* fall through - CHECK_STOP and LOAD are not supported yet */ > default: > rc = -ENXIO; > > This created a bit of an API asymmetry where: > - Documentation/virt/kvm/api.rst:1546 [5] advertises CHECK_STOP as valid > - KVM_SET_MP_STATE rejects it with -ENXIO > - KVM_GET_MP_STATE never returns it (always returns STOPPED or OPERATING) [6] > >> Now: The architecture defines that state and the interface is certainly >> there. So implementing it will allow userspace to put a CPU into checkstop >> state if you ever need that. We also have a checkstop state that you >> can put a secure CPU in. >> >> The usecase is dubious though. The only case of the options from POP >> chapter11 that makes sense to me in a virtualized environment is an exigent >> machine check but a problem to actually deliver that (multiple reasons, >> like the OS has machine checks disabled in PSW, or the prefix register >> is broken). >> >> So I am curious, do you have any specific usecase in mind? >> I assume you have a related QEMU patch somewhere? > > The use cases I see are: > > 1. API completeness: The state was added to the UAPI 11 years ago but never > implemented. Userspace cannot use a documented API feature. I'd rather have stubs which properly fence than code that's never tested since we don't use it. Since this never worked it might make sense to remove it since future users will need to check for this "feature" anyway before using it. > > 2. Fault injection testing: Administrators testing failover/monitoring for > hardware failures could programmatically put a CPU into CHECK_STOP to > verify their procedures work. How would that work? What can we gain from putting a CPU into checkstop? How would QEMU use this? Checkstop is not an error communication medium, that's the machine check interrupt. If you want to inject faults then use the machine check interface. If you want to crash the guest, then panic it or just stop cpus.
© 2016 - 2025 Red Hat, Inc.