Re: [PATCH] KVM: s390: Implement CHECK_STOP support and fix GET_MP_STATE
From: Josephine Pfeiffer
Date: Thu Dec 11 2025 - 05:59:45 EST
On Tue, 25 Nov 2025 19:10:43 +0100, Janosch Frank wrote:
> On 11/20/25 19:28, Josephine Pfeiffer wrote:
> > 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.
That's a fair point. If you think there's no real use case, removing the dead
API is cleaner than implementing unused code.
> > 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 would 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.
You're right - machine check interrupts are the correct mechanism for fault
injection. I was conflating the error state with error signaling.
I'll withdraw this patch and can send a cleanup patch instead to remove
KVM_MP_STATE_CHECK_STOP from the documentation. Would that be useful?
If so, should I also remove KVM_MP_STATE_LOAD from the docs while I'm at it? It has
the same "not supported yet" comment from the original 2014 commit [1].
Thanks,
Josephine
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6352e4d2dd9a