linux-s390.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] KVM: s390: Add capability that forwards operation exceptions
@ 2025-10-29 13:04 Janosch Frank
  2025-10-29 14:07 ` Claudio Imbrenda
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Janosch Frank @ 2025-10-29 13:04 UTC (permalink / raw)
  To: kvm; +Cc: linux-s390, imbrenda, borntraeger

Setting KVM_CAP_S390_USER_OPEREXEC will forward all operation
exceptions to user space. This also includes the 0x0000 instructions
managed by KVM_CAP_S390_USER_INSTR0. It's helpful if user space wants
to emulate instructions which do not (yet) have an opcode.

While we're at it refine the documentation for
KVM_CAP_S390_USER_INSTR0.

Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
---

This is based on the api documentation ordering fix that's in our next
branch.

---
 Documentation/virt/kvm/api.rst                |  17 ++-
 arch/s390/include/asm/kvm_host.h              |   1 +
 arch/s390/kvm/intercept.c                     |   3 +
 arch/s390/kvm/kvm-s390.c                      |   7 +
 include/uapi/linux/kvm.h                      |   1 +
 tools/testing/selftests/kvm/Makefile.kvm      |   1 +
 .../selftests/kvm/s390/user_operexec.c        | 140 ++++++++++++++++++
 7 files changed, 169 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/kvm/s390/user_operexec.c

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 72b2fae99a83..67837207dc9b 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -7820,7 +7820,7 @@ where 0xff represents CPUs 0-7 in cluster 0.
 :Architectures: s390
 :Parameters: none
 
-With this capability enabled, all illegal instructions 0x0000 (2 bytes) will
+With this capability enabled, the illegal instruction 0x0000 (2 bytes) will
 be intercepted and forwarded to user space. User space can use this
 mechanism e.g. to realize 2-byte software breakpoints. The kernel will
 not inject an operating exception for these instructions, user space has
@@ -8703,6 +8703,21 @@ This capability indicate to the userspace whether a PFNMAP memory region
 can be safely mapped as cacheable. This relies on the presence of
 force write back (FWB) feature support on the hardware.
 
+7.45 KVM_CAP_S390_USER_OPEREXEC
+----------------------------
+
+:Architectures: s390
+:Parameters: none
+
+When this capability is enabled KVM forwards all operation exceptions
+that it doesn't handle itself to user space. This also includes the
+0x0000 instructions managed by KVM_CAP_S390_USER_INSTR0. This is
+helpful if user space wants to emulate instructions which do not (yet)
+have an opcode.
+
+This capability can be enabled dynamically even if VCPUs were already
+created and are running.
+
 8. Other capabilities.
 ======================
 
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 22cedcaea475..1e4829c70216 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -648,6 +648,7 @@ struct kvm_arch {
 	int user_sigp;
 	int user_stsi;
 	int user_instr0;
+	int user_operexec;
 	struct s390_io_adapter *adapters[MAX_S390_IO_ADAPTERS];
 	wait_queue_head_t ipte_wq;
 	int ipte_lock_count;
diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
index c7908950c1f4..420ae62977e2 100644
--- a/arch/s390/kvm/intercept.c
+++ b/arch/s390/kvm/intercept.c
@@ -471,6 +471,9 @@ static int handle_operexc(struct kvm_vcpu *vcpu)
 	if (vcpu->arch.sie_block->ipa == 0xb256)
 		return handle_sthyi(vcpu);
 
+	if (vcpu->kvm->arch.user_operexec)
+		return -EOPNOTSUPP;
+
 	if (vcpu->arch.sie_block->ipa == 0 && vcpu->kvm->arch.user_instr0)
 		return -EOPNOTSUPP;
 	rc = read_guest_lc(vcpu, __LC_PGM_NEW_PSW, &newpsw, sizeof(psw_t));
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 70ebc54b1bb1..56d4730b7c41 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -606,6 +606,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
 	case KVM_CAP_SET_GUEST_DEBUG:
 	case KVM_CAP_S390_DIAG318:
 	case KVM_CAP_IRQFD_RESAMPLE:
+	case KVM_CAP_S390_USER_OPEREXEC:
 		r = 1;
 		break;
 	case KVM_CAP_SET_GUEST_DEBUG2:
@@ -921,6 +922,12 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
 		VM_EVENT(kvm, 3, "ENABLE: CAP_S390_CPU_TOPOLOGY %s",
 			 r ? "(not available)" : "(success)");
 		break;
+	case KVM_CAP_S390_USER_OPEREXEC:
+		VM_EVENT(kvm, 3, "%s", "ENABLE: CAP_S390_USER_OPEREXEC");
+		kvm->arch.user_operexec = 1;
+		icpt_operexc_on_all_vcpus(kvm);
+		r = 0;
+		break;
 	default:
 		r = -EINVAL;
 		break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 52f6000ab020..8ab07396ce3b 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -963,6 +963,7 @@ struct kvm_enable_cap {
 #define KVM_CAP_RISCV_MP_STATE_RESET 242
 #define KVM_CAP_ARM_CACHEABLE_PFNMAP_SUPPORTED 243
 #define KVM_CAP_GUEST_MEMFD_FLAGS 244
+#define KVM_CAP_S390_USER_OPEREXEC 245
 
 struct kvm_irq_routing_irqchip {
 	__u32 irqchip;
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 148d427ff24b..87e429206bb8 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -194,6 +194,7 @@ TEST_GEN_PROGS_s390 += s390/debug_test
 TEST_GEN_PROGS_s390 += s390/cpumodel_subfuncs_test
 TEST_GEN_PROGS_s390 += s390/shared_zeropage_test
 TEST_GEN_PROGS_s390 += s390/ucontrol_test
+TEST_GEN_PROGS_s390 += s390/user_operexec
 TEST_GEN_PROGS_s390 += rseq_test
 
 TEST_GEN_PROGS_riscv = $(TEST_GEN_PROGS_COMMON)
diff --git a/tools/testing/selftests/kvm/s390/user_operexec.c b/tools/testing/selftests/kvm/s390/user_operexec.c
new file mode 100644
index 000000000000..714906c1d12a
--- /dev/null
+++ b/tools/testing/selftests/kvm/s390/user_operexec.c
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Test operation exception forwarding.
+ *
+ * Copyright IBM Corp. 2025
+ *
+ * Authors:
+ *  Janosch Frank <frankja@linux.ibm.com>
+ */
+#include "kselftest.h"
+#include "kvm_util.h"
+#include "test_util.h"
+#include "sie.h"
+
+#include <linux/kvm.h>
+
+static void guest_code_instr0(void)
+{
+	asm(".word 0x0000");
+}
+
+static void test_user_instr0(void)
+{
+	struct kvm_vcpu *vcpu;
+	struct kvm_vm *vm;
+	int rc;
+
+	vm = vm_create_with_one_vcpu(&vcpu, guest_code_instr0);
+	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
+	TEST_ASSERT_EQ(0, rc);
+
+	vcpu_run(vcpu);
+	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
+	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
+	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0);
+
+	kvm_vm_free(vm);
+}
+
+static void guest_code_user_operexec(void)
+{
+	asm(".word 0x0807");
+}
+
+static void test_user_operexec(void)
+{
+	struct kvm_vcpu *vcpu;
+	struct kvm_vm *vm;
+	int rc;
+
+	vm = vm_create_with_one_vcpu(&vcpu, guest_code_user_operexec);
+	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
+	TEST_ASSERT_EQ(0, rc);
+
+	vcpu_run(vcpu);
+	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
+	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
+	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0x0807);
+
+	kvm_vm_free(vm);
+
+	/*
+	 * Since user_operexec is the superset it can be used for the
+	 * 0 instruction.
+	 */
+	vm = vm_create_with_one_vcpu(&vcpu, guest_code_instr0);
+	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
+	TEST_ASSERT_EQ(0, rc);
+
+	vcpu_run(vcpu);
+	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
+	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
+	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0);
+
+	kvm_vm_free(vm);
+}
+
+/* combine user_instr0 and user_operexec */
+static void test_user_operexec_combined(void)
+{
+	struct kvm_vcpu *vcpu;
+	struct kvm_vm *vm;
+	int rc;
+
+	vm = vm_create_with_one_vcpu(&vcpu, guest_code_user_operexec);
+	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
+	TEST_ASSERT_EQ(0, rc);
+	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
+	TEST_ASSERT_EQ(0, rc);
+
+	vcpu_run(vcpu);
+	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
+	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
+	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0x0807);
+
+	kvm_vm_free(vm);
+
+	/* Reverse enablement order */
+	vm = vm_create_with_one_vcpu(&vcpu, guest_code_user_operexec);
+	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
+	TEST_ASSERT_EQ(0, rc);
+	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
+	TEST_ASSERT_EQ(0, rc);
+
+	vcpu_run(vcpu);
+	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
+	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
+	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0x0807);
+
+	kvm_vm_free(vm);
+}
+
+/*
+ * Run all tests above.
+ *
+ * Enablement after VCPU has been added is automatically tested since
+ * we enable the capability after VCPU creation.
+ */
+static struct testdef {
+	const char *name;
+	void (*test)(void);
+} testlist[] = {
+	{ "instr0", test_user_instr0 },
+	{ "operexec", test_user_operexec },
+	{ "operexec_combined", test_user_operexec_combined},
+};
+
+int main(int argc, char *argv[])
+{
+	int idx;
+
+	TEST_REQUIRE(kvm_has_cap(KVM_CAP_S390_USER_INSTR0));
+
+	ksft_print_header();
+	ksft_set_plan(ARRAY_SIZE(testlist));
+	for (idx = 0; idx < ARRAY_SIZE(testlist); idx++) {
+		testlist[idx].test();
+		ksft_test_result_pass("%s\n", testlist[idx].name);
+	}
+	ksft_finished();
+}
-- 
2.48.1


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] KVM: s390: Add capability that forwards operation exceptions
  2025-10-29 13:04 [PATCH] KVM: s390: Add capability that forwards operation exceptions Janosch Frank
@ 2025-10-29 14:07 ` Claudio Imbrenda
  2025-10-29 16:32 ` Christian Borntraeger
  2025-10-30  7:10 ` Thomas Huth
  2 siblings, 0 replies; 6+ messages in thread
From: Claudio Imbrenda @ 2025-10-29 14:07 UTC (permalink / raw)
  To: Janosch Frank; +Cc: kvm, linux-s390, borntraeger

On Wed, 29 Oct 2025 13:04:11 +0000
Janosch Frank <frankja@linux.ibm.com> wrote:

> Setting KVM_CAP_S390_USER_OPEREXEC will forward all operation
> exceptions to user space. This also includes the 0x0000 instructions
> managed by KVM_CAP_S390_USER_INSTR0. It's helpful if user space wants
> to emulate instructions which do not (yet) have an opcode.
> 
> While we're at it refine the documentation for
> KVM_CAP_S390_USER_INSTR0.
> 
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>

Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>

> ---
> 
> This is based on the api documentation ordering fix that's in our next
> branch.
> 
> ---
>  Documentation/virt/kvm/api.rst                |  17 ++-
>  arch/s390/include/asm/kvm_host.h              |   1 +
>  arch/s390/kvm/intercept.c                     |   3 +
>  arch/s390/kvm/kvm-s390.c                      |   7 +
>  include/uapi/linux/kvm.h                      |   1 +
>  tools/testing/selftests/kvm/Makefile.kvm      |   1 +
>  .../selftests/kvm/s390/user_operexec.c        | 140 ++++++++++++++++++
>  7 files changed, 169 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/kvm/s390/user_operexec.c
> 
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 72b2fae99a83..67837207dc9b 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -7820,7 +7820,7 @@ where 0xff represents CPUs 0-7 in cluster 0.
>  :Architectures: s390
>  :Parameters: none
>  
> -With this capability enabled, all illegal instructions 0x0000 (2 bytes) will
> +With this capability enabled, the illegal instruction 0x0000 (2 bytes) will
>  be intercepted and forwarded to user space. User space can use this
>  mechanism e.g. to realize 2-byte software breakpoints. The kernel will
>  not inject an operating exception for these instructions, user space has
> @@ -8703,6 +8703,21 @@ This capability indicate to the userspace whether a PFNMAP memory region
>  can be safely mapped as cacheable. This relies on the presence of
>  force write back (FWB) feature support on the hardware.
>  
> +7.45 KVM_CAP_S390_USER_OPEREXEC
> +----------------------------
> +
> +:Architectures: s390
> +:Parameters: none
> +
> +When this capability is enabled KVM forwards all operation exceptions
> +that it doesn't handle itself to user space. This also includes the
> +0x0000 instructions managed by KVM_CAP_S390_USER_INSTR0. This is
> +helpful if user space wants to emulate instructions which do not (yet)
> +have an opcode.
> +
> +This capability can be enabled dynamically even if VCPUs were already
> +created and are running.
> +
>  8. Other capabilities.
>  ======================
>  
> diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
> index 22cedcaea475..1e4829c70216 100644
> --- a/arch/s390/include/asm/kvm_host.h
> +++ b/arch/s390/include/asm/kvm_host.h
> @@ -648,6 +648,7 @@ struct kvm_arch {
>  	int user_sigp;
>  	int user_stsi;
>  	int user_instr0;
> +	int user_operexec;
>  	struct s390_io_adapter *adapters[MAX_S390_IO_ADAPTERS];
>  	wait_queue_head_t ipte_wq;
>  	int ipte_lock_count;
> diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
> index c7908950c1f4..420ae62977e2 100644
> --- a/arch/s390/kvm/intercept.c
> +++ b/arch/s390/kvm/intercept.c
> @@ -471,6 +471,9 @@ static int handle_operexc(struct kvm_vcpu *vcpu)
>  	if (vcpu->arch.sie_block->ipa == 0xb256)
>  		return handle_sthyi(vcpu);
>  
> +	if (vcpu->kvm->arch.user_operexec)
> +		return -EOPNOTSUPP;
> +
>  	if (vcpu->arch.sie_block->ipa == 0 && vcpu->kvm->arch.user_instr0)
>  		return -EOPNOTSUPP;
>  	rc = read_guest_lc(vcpu, __LC_PGM_NEW_PSW, &newpsw, sizeof(psw_t));
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 70ebc54b1bb1..56d4730b7c41 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -606,6 +606,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>  	case KVM_CAP_SET_GUEST_DEBUG:
>  	case KVM_CAP_S390_DIAG318:
>  	case KVM_CAP_IRQFD_RESAMPLE:
> +	case KVM_CAP_S390_USER_OPEREXEC:
>  		r = 1;
>  		break;
>  	case KVM_CAP_SET_GUEST_DEBUG2:
> @@ -921,6 +922,12 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
>  		VM_EVENT(kvm, 3, "ENABLE: CAP_S390_CPU_TOPOLOGY %s",
>  			 r ? "(not available)" : "(success)");
>  		break;
> +	case KVM_CAP_S390_USER_OPEREXEC:
> +		VM_EVENT(kvm, 3, "%s", "ENABLE: CAP_S390_USER_OPEREXEC");
> +		kvm->arch.user_operexec = 1;
> +		icpt_operexc_on_all_vcpus(kvm);
> +		r = 0;
> +		break;
>  	default:
>  		r = -EINVAL;
>  		break;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 52f6000ab020..8ab07396ce3b 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -963,6 +963,7 @@ struct kvm_enable_cap {
>  #define KVM_CAP_RISCV_MP_STATE_RESET 242
>  #define KVM_CAP_ARM_CACHEABLE_PFNMAP_SUPPORTED 243
>  #define KVM_CAP_GUEST_MEMFD_FLAGS 244
> +#define KVM_CAP_S390_USER_OPEREXEC 245
>  
>  struct kvm_irq_routing_irqchip {
>  	__u32 irqchip;
> diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
> index 148d427ff24b..87e429206bb8 100644
> --- a/tools/testing/selftests/kvm/Makefile.kvm
> +++ b/tools/testing/selftests/kvm/Makefile.kvm
> @@ -194,6 +194,7 @@ TEST_GEN_PROGS_s390 += s390/debug_test
>  TEST_GEN_PROGS_s390 += s390/cpumodel_subfuncs_test
>  TEST_GEN_PROGS_s390 += s390/shared_zeropage_test
>  TEST_GEN_PROGS_s390 += s390/ucontrol_test
> +TEST_GEN_PROGS_s390 += s390/user_operexec
>  TEST_GEN_PROGS_s390 += rseq_test
>  
>  TEST_GEN_PROGS_riscv = $(TEST_GEN_PROGS_COMMON)
> diff --git a/tools/testing/selftests/kvm/s390/user_operexec.c b/tools/testing/selftests/kvm/s390/user_operexec.c
> new file mode 100644
> index 000000000000..714906c1d12a
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/s390/user_operexec.c
> @@ -0,0 +1,140 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Test operation exception forwarding.
> + *
> + * Copyright IBM Corp. 2025
> + *
> + * Authors:
> + *  Janosch Frank <frankja@linux.ibm.com>
> + */
> +#include "kselftest.h"
> +#include "kvm_util.h"
> +#include "test_util.h"
> +#include "sie.h"
> +
> +#include <linux/kvm.h>
> +
> +static void guest_code_instr0(void)
> +{
> +	asm(".word 0x0000");
> +}
> +
> +static void test_user_instr0(void)
> +{
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	int rc;
> +
> +	vm = vm_create_with_one_vcpu(&vcpu, guest_code_instr0);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu_run(vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0);
> +
> +	kvm_vm_free(vm);
> +}
> +
> +static void guest_code_user_operexec(void)
> +{
> +	asm(".word 0x0807");
> +}
> +
> +static void test_user_operexec(void)
> +{
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	int rc;
> +
> +	vm = vm_create_with_one_vcpu(&vcpu, guest_code_user_operexec);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu_run(vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0x0807);
> +
> +	kvm_vm_free(vm);
> +
> +	/*
> +	 * Since user_operexec is the superset it can be used for the
> +	 * 0 instruction.
> +	 */
> +	vm = vm_create_with_one_vcpu(&vcpu, guest_code_instr0);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu_run(vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0);
> +
> +	kvm_vm_free(vm);
> +}
> +
> +/* combine user_instr0 and user_operexec */
> +static void test_user_operexec_combined(void)
> +{
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	int rc;
> +
> +	vm = vm_create_with_one_vcpu(&vcpu, guest_code_user_operexec);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu_run(vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0x0807);
> +
> +	kvm_vm_free(vm);
> +
> +	/* Reverse enablement order */
> +	vm = vm_create_with_one_vcpu(&vcpu, guest_code_user_operexec);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu_run(vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0x0807);
> +
> +	kvm_vm_free(vm);
> +}
> +
> +/*
> + * Run all tests above.
> + *
> + * Enablement after VCPU has been added is automatically tested since
> + * we enable the capability after VCPU creation.
> + */
> +static struct testdef {
> +	const char *name;
> +	void (*test)(void);
> +} testlist[] = {
> +	{ "instr0", test_user_instr0 },
> +	{ "operexec", test_user_operexec },
> +	{ "operexec_combined", test_user_operexec_combined},
> +};
> +
> +int main(int argc, char *argv[])
> +{
> +	int idx;
> +
> +	TEST_REQUIRE(kvm_has_cap(KVM_CAP_S390_USER_INSTR0));
> +
> +	ksft_print_header();
> +	ksft_set_plan(ARRAY_SIZE(testlist));
> +	for (idx = 0; idx < ARRAY_SIZE(testlist); idx++) {
> +		testlist[idx].test();
> +		ksft_test_result_pass("%s\n", testlist[idx].name);
> +	}
> +	ksft_finished();
> +}


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] KVM: s390: Add capability that forwards operation exceptions
  2025-10-29 13:04 [PATCH] KVM: s390: Add capability that forwards operation exceptions Janosch Frank
  2025-10-29 14:07 ` Claudio Imbrenda
@ 2025-10-29 16:32 ` Christian Borntraeger
  2025-10-30  7:10 ` Thomas Huth
  2 siblings, 0 replies; 6+ messages in thread
From: Christian Borntraeger @ 2025-10-29 16:32 UTC (permalink / raw)
  To: Janosch Frank, kvm; +Cc: linux-s390, imbrenda

Am 29.10.25 um 14:04 schrieb Janosch Frank:
> Setting KVM_CAP_S390_USER_OPEREXEC will forward all operation
> exceptions to user space. This also includes the 0x0000 instructions
> managed by KVM_CAP_S390_USER_INSTR0. It's helpful if user space wants
> to emulate instructions which do not (yet) have an opcode.
> 
> While we're at it refine the documentation for
> KVM_CAP_S390_USER_INSTR0.

An alternative would be to add a flag to KVM_CAP_S390_USER_INSTR0, but I am not sure if this
has any real benefit or downside.> 
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>

But this looks good,

Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] KVM: s390: Add capability that forwards operation exceptions
  2025-10-29 13:04 [PATCH] KVM: s390: Add capability that forwards operation exceptions Janosch Frank
  2025-10-29 14:07 ` Claudio Imbrenda
  2025-10-29 16:32 ` Christian Borntraeger
@ 2025-10-30  7:10 ` Thomas Huth
  2025-10-31  8:45   ` Janosch Frank
  2 siblings, 1 reply; 6+ messages in thread
From: Thomas Huth @ 2025-10-30  7:10 UTC (permalink / raw)
  To: Janosch Frank, kvm; +Cc: linux-s390, imbrenda, borntraeger

On 29/10/2025 14.04, Janosch Frank wrote:
> Setting KVM_CAP_S390_USER_OPEREXEC will forward all operation
> exceptions to user space. This also includes the 0x0000 instructions
> managed by KVM_CAP_S390_USER_INSTR0. It's helpful if user space wants
> to emulate instructions which do not (yet) have an opcode.
> 
> While we're at it refine the documentation for
> KVM_CAP_S390_USER_INSTR0.
> 
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
...
> +7.45 KVM_CAP_S390_USER_OPEREXEC
> +----------------------------
> +
> +:Architectures: s390
> +:Parameters: none
> +
> +When this capability is enabled KVM forwards all operation exceptions
> +that it doesn't handle itself to user space. This also includes the
> +0x0000 instructions managed by KVM_CAP_S390_USER_INSTR0. This is
> +helpful if user space wants to emulate instructions which do not (yet)
> +have an opcode.

"which do not (yet) have an opcode" sounds a little bit weird. Maybe rather: 
"which are not (yet) implemented in the current CPU" or so?

> +This capability can be enabled dynamically even if VCPUs were already
> +created and are running.
> +
>   8. Other capabilities.
>   ======================
...
> diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
> index c7908950c1f4..420ae62977e2 100644
> --- a/arch/s390/kvm/intercept.c
> +++ b/arch/s390/kvm/intercept.c
> @@ -471,6 +471,9 @@ static int handle_operexc(struct kvm_vcpu *vcpu)
>   	if (vcpu->arch.sie_block->ipa == 0xb256)
>   		return handle_sthyi(vcpu);
>   
> +	if (vcpu->kvm->arch.user_operexec)
> +		return -EOPNOTSUPP;
> +
>   	if (vcpu->arch.sie_block->ipa == 0 && vcpu->kvm->arch.user_instr0)
>   		return -EOPNOTSUPP;
>   	rc = read_guest_lc(vcpu, __LC_PGM_NEW_PSW, &newpsw, sizeof(psw_t));
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 70ebc54b1bb1..56d4730b7c41 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -606,6 +606,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>   	case KVM_CAP_SET_GUEST_DEBUG:
>   	case KVM_CAP_S390_DIAG318:
>   	case KVM_CAP_IRQFD_RESAMPLE:
> +	case KVM_CAP_S390_USER_OPEREXEC:
>   		r = 1;
>   		break;
>   	case KVM_CAP_SET_GUEST_DEBUG2:
> @@ -921,6 +922,12 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
>   		VM_EVENT(kvm, 3, "ENABLE: CAP_S390_CPU_TOPOLOGY %s",
>   			 r ? "(not available)" : "(success)");
>   		break;
> +	case KVM_CAP_S390_USER_OPEREXEC:
> +		VM_EVENT(kvm, 3, "%s", "ENABLE: CAP_S390_USER_OPEREXEC");
> +		kvm->arch.user_operexec = 1;
> +		icpt_operexc_on_all_vcpus(kvm);

Maybe check cap->flags here and return with an error if any flag is set? ... 
otherwise, if we ever add flags here, userspace cannot check whether the 
kernel accepted a flag or not.

> +		r = 0;
> +		break;
>   	default:
>   		r = -EINVAL;
>   		break;
...
> diff --git a/tools/testing/selftests/kvm/s390/user_operexec.c b/tools/testing/selftests/kvm/s390/user_operexec.c
> new file mode 100644
> index 000000000000..714906c1d12a
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/s390/user_operexec.c
> @@ -0,0 +1,140 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Test operation exception forwarding.
> + *
> + * Copyright IBM Corp. 2025
> + *
> + * Authors:
> + *  Janosch Frank <frankja@linux.ibm.com>
> + */
> +#include "kselftest.h"
> +#include "kvm_util.h"
> +#include "test_util.h"
> +#include "sie.h"
> +
> +#include <linux/kvm.h>
> +
> +static void guest_code_instr0(void)
> +{
> +	asm(".word 0x0000");
> +}
> +
> +static void test_user_instr0(void)
> +{
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	int rc;
> +
> +	vm = vm_create_with_one_vcpu(&vcpu, guest_code_instr0);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu_run(vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0);
> +
> +	kvm_vm_free(vm);
> +}
> +
> +static void guest_code_user_operexec(void)
> +{
> +	asm(".word 0x0807");
> +}
> +
> +static void test_user_operexec(void)
> +{
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	int rc;
> +
> +	vm = vm_create_with_one_vcpu(&vcpu, guest_code_user_operexec);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu_run(vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0x0807);
> +
> +	kvm_vm_free(vm);
> +
> +	/*
> +	 * Since user_operexec is the superset it can be used for the
> +	 * 0 instruction.
> +	 */
> +	vm = vm_create_with_one_vcpu(&vcpu, guest_code_instr0);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu_run(vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0);
> +
> +	kvm_vm_free(vm);
> +}
> +
> +/* combine user_instr0 and user_operexec */
> +static void test_user_operexec_combined(void)
> +{
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	int rc;
> +
> +	vm = vm_create_with_one_vcpu(&vcpu, guest_code_user_operexec);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu_run(vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0x0807);
> +
> +	kvm_vm_free(vm);
> +
> +	/* Reverse enablement order */
> +	vm = vm_create_with_one_vcpu(&vcpu, guest_code_user_operexec);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu_run(vcpu);
> +	TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_S390_SIEIC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.icptcode, ICPT_OPEREXC);
> +	TEST_ASSERT_EQ(vcpu->run->s390_sieic.ipa, 0x0807);
> +
> +	kvm_vm_free(vm);
> +}
> +
> +/*
> + * Run all tests above.
> + *
> + * Enablement after VCPU has been added is automatically tested since
> + * we enable the capability after VCPU creation.
> + */
> +static struct testdef {
> +	const char *name;
> +	void (*test)(void);
> +} testlist[] = {
> +	{ "instr0", test_user_instr0 },
> +	{ "operexec", test_user_operexec },
> +	{ "operexec_combined", test_user_operexec_combined},
> +};
> +
> +int main(int argc, char *argv[])
> +{
> +	int idx;
> +
> +	TEST_REQUIRE(kvm_has_cap(KVM_CAP_S390_USER_INSTR0));
> +
> +	ksft_print_header();
> +	ksft_set_plan(ARRAY_SIZE(testlist));
> +	for (idx = 0; idx < ARRAY_SIZE(testlist); idx++) {
> +		testlist[idx].test();
> +		ksft_test_result_pass("%s\n", testlist[idx].name);
> +	}
> +	ksft_finished();
> +}

You could likely use the KVM_ONE_VCPU_TEST() macro and test_harness_run() to 
get rid of the boilerplate code here.

  Thomas


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] KVM: s390: Add capability that forwards operation exceptions
  2025-10-30  7:10 ` Thomas Huth
@ 2025-10-31  8:45   ` Janosch Frank
  2025-10-31  9:36     ` Thomas Huth
  0 siblings, 1 reply; 6+ messages in thread
From: Janosch Frank @ 2025-10-31  8:45 UTC (permalink / raw)
  To: Thomas Huth, kvm; +Cc: linux-s390, imbrenda, borntraeger

On 10/30/25 08:10, Thomas Huth wrote:
> On 29/10/2025 14.04, Janosch Frank wrote:
>> Setting KVM_CAP_S390_USER_OPEREXEC will forward all operation
>> exceptions to user space. This also includes the 0x0000 instructions
>> managed by KVM_CAP_S390_USER_INSTR0. It's helpful if user space wants
>> to emulate instructions which do not (yet) have an opcode.
>>
>> While we're at it refine the documentation for
>> KVM_CAP_S390_USER_INSTR0.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> ...
>> +7.45 KVM_CAP_S390_USER_OPEREXEC
>> +----------------------------
>> +
>> +:Architectures: s390
>> +:Parameters: none
>> +
>> +When this capability is enabled KVM forwards all operation exceptions
>> +that it doesn't handle itself to user space. This also includes the
>> +0x0000 instructions managed by KVM_CAP_S390_USER_INSTR0. This is
>> +helpful if user space wants to emulate instructions which do not (yet)
>> +have an opcode.
> 
> "which do not (yet) have an opcode" sounds a little bit weird. Maybe rather:
> "which are not (yet) implemented in the current CPU" or so?

How about:
...which are not (yet) implemented in hardware.


> 
>> +This capability can be enabled dynamically even if VCPUs were already
>> +created and are running.
>> +
>>    8. Other capabilities.
>>    ======================
> ...
>> diff --git a/arch/s390/kvm/intercept.c b/arch/s390/kvm/intercept.c
>> index c7908950c1f4..420ae62977e2 100644
>> --- a/arch/s390/kvm/intercept.c
>> +++ b/arch/s390/kvm/intercept.c
>> @@ -471,6 +471,9 @@ static int handle_operexc(struct kvm_vcpu *vcpu)
>>    	if (vcpu->arch.sie_block->ipa == 0xb256)
>>    		return handle_sthyi(vcpu);
>>    
>> +	if (vcpu->kvm->arch.user_operexec)
>> +		return -EOPNOTSUPP;
>> +
>>    	if (vcpu->arch.sie_block->ipa == 0 && vcpu->kvm->arch.user_instr0)
>>    		return -EOPNOTSUPP;
>>    	rc = read_guest_lc(vcpu, __LC_PGM_NEW_PSW, &newpsw, sizeof(psw_t));
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index 70ebc54b1bb1..56d4730b7c41 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -606,6 +606,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
>>    	case KVM_CAP_SET_GUEST_DEBUG:
>>    	case KVM_CAP_S390_DIAG318:
>>    	case KVM_CAP_IRQFD_RESAMPLE:
>> +	case KVM_CAP_S390_USER_OPEREXEC:
>>    		r = 1;
>>    		break;
>>    	case KVM_CAP_SET_GUEST_DEBUG2:
>> @@ -921,6 +922,12 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
>>    		VM_EVENT(kvm, 3, "ENABLE: CAP_S390_CPU_TOPOLOGY %s",
>>    			 r ? "(not available)" : "(success)");
>>    		break;
>> +	case KVM_CAP_S390_USER_OPEREXEC:
>> +		VM_EVENT(kvm, 3, "%s", "ENABLE: CAP_S390_USER_OPEREXEC");
>> +		kvm->arch.user_operexec = 1;
>> +		icpt_operexc_on_all_vcpus(kvm);
> 
> Maybe check cap->flags here and return with an error if any flag is set? ...
> otherwise, if we ever add flags here, userspace cannot check whether the
> kernel accepted a flag or not.

Check the top of the function :)
I can surely add a second check to be doubly sure.

int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
{
         int r;

         if (cap->flags)
                 return -EINVAL;



>> +/*
>> + * Run all tests above.
>> + *
>> + * Enablement after VCPU has been added is automatically tested since
>> + * we enable the capability after VCPU creation.
>> + */
>> +static struct testdef {
>> +	const char *name;
>> +	void (*test)(void);
>> +} testlist[] = {
>> +	{ "instr0", test_user_instr0 },
>> +	{ "operexec", test_user_operexec },
>> +	{ "operexec_combined", test_user_operexec_combined},
>> +};
>> +
>> +int main(int argc, char *argv[])
>> +{
>> +	int idx;
>> +
>> +	TEST_REQUIRE(kvm_has_cap(KVM_CAP_S390_USER_INSTR0));
>> +
>> +	ksft_print_header();
>> +	ksft_set_plan(ARRAY_SIZE(testlist));
>> +	for (idx = 0; idx < ARRAY_SIZE(testlist); idx++) {
>> +		testlist[idx].test();
>> +		ksft_test_result_pass("%s\n", testlist[idx].name);
>> +	}
>> +	ksft_finished();
>> +}
> 
> You could likely use the KVM_ONE_VCPU_TEST() macro and test_harness_run() to
> get rid of the boilerplate code here.

Is there a general directive to use KVM_ONE_VCPU_TEST?
To be honest I prefer the look as is since it doesn't hide things behind 
macros and 95% of our tests use it.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] KVM: s390: Add capability that forwards operation exceptions
  2025-10-31  8:45   ` Janosch Frank
@ 2025-10-31  9:36     ` Thomas Huth
  0 siblings, 0 replies; 6+ messages in thread
From: Thomas Huth @ 2025-10-31  9:36 UTC (permalink / raw)
  To: Janosch Frank, kvm; +Cc: linux-s390, imbrenda, borntraeger

On 31/10/2025 09.45, Janosch Frank wrote:
> On 10/30/25 08:10, Thomas Huth wrote:
>> On 29/10/2025 14.04, Janosch Frank wrote:
>>> Setting KVM_CAP_S390_USER_OPEREXEC will forward all operation
>>> exceptions to user space. This also includes the 0x0000 instructions
>>> managed by KVM_CAP_S390_USER_INSTR0. It's helpful if user space wants
>>> to emulate instructions which do not (yet) have an opcode.
>>>
>>> While we're at it refine the documentation for
>>> KVM_CAP_S390_USER_INSTR0.
>>>
>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> ...
>>> +7.45 KVM_CAP_S390_USER_OPEREXEC
>>> +----------------------------
>>> +
>>> +:Architectures: s390
>>> +:Parameters: none
>>> +
>>> +When this capability is enabled KVM forwards all operation exceptions
>>> +that it doesn't handle itself to user space. This also includes the
>>> +0x0000 instructions managed by KVM_CAP_S390_USER_INSTR0. This is
>>> +helpful if user space wants to emulate instructions which do not (yet)
>>> +have an opcode.
>>
>> "which do not (yet) have an opcode" sounds a little bit weird. Maybe rather:
>> "which are not (yet) implemented in the current CPU" or so?
> 
> How about:
> ...which are not (yet) implemented in hardware.

Sounds good!


>>> @@ -921,6 +922,12 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct 
>>> kvm_enable_cap *cap)
>>>            VM_EVENT(kvm, 3, "ENABLE: CAP_S390_CPU_TOPOLOGY %s",
>>>                 r ? "(not available)" : "(success)");
>>>            break;
>>> +    case KVM_CAP_S390_USER_OPEREXEC:
>>> +        VM_EVENT(kvm, 3, "%s", "ENABLE: CAP_S390_USER_OPEREXEC");
>>> +        kvm->arch.user_operexec = 1;
>>> +        icpt_operexc_on_all_vcpus(kvm);
>>
>> Maybe check cap->flags here and return with an error if any flag is set? ...
>> otherwise, if we ever add flags here, userspace cannot check whether the
>> kernel accepted a flag or not.
> 
> Check the top of the function :)

Ah, I missed that, so it should already be fine!


>>> + * Run all tests above.
>>> + *
>>> + * Enablement after VCPU has been added is automatically tested since
>>> + * we enable the capability after VCPU creation.
>>> + */
>>> +static struct testdef {
>>> +    const char *name;
>>> +    void (*test)(void);
>>> +} testlist[] = {
>>> +    { "instr0", test_user_instr0 },
>>> +    { "operexec", test_user_operexec },
>>> +    { "operexec_combined", test_user_operexec_combined},
>>> +};
>>> +
>>> +int main(int argc, char *argv[])
>>> +{
>>> +    int idx;
>>> +
>>> +    TEST_REQUIRE(kvm_has_cap(KVM_CAP_S390_USER_INSTR0));
>>> +
>>> +    ksft_print_header();
>>> +    ksft_set_plan(ARRAY_SIZE(testlist));
>>> +    for (idx = 0; idx < ARRAY_SIZE(testlist); idx++) {
>>> +        testlist[idx].test();
>>> +        ksft_test_result_pass("%s\n", testlist[idx].name);
>>> +    }
>>> +    ksft_finished();
>>> +}
>>
>> You could likely use the KVM_ONE_VCPU_TEST() macro and test_harness_run() to
>> get rid of the boilerplate code here.
> 
> Is there a general directive to use KVM_ONE_VCPU_TEST?

Certainly not from my side!
(but Sean might have a different opinion on this topic ;-))

> To be honest I prefer the look as is since it doesn't hide things behind 
> macros and 95% of our tests use it.

Fine for me, too.

  Thomas


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2025-10-31  9:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-29 13:04 [PATCH] KVM: s390: Add capability that forwards operation exceptions Janosch Frank
2025-10-29 14:07 ` Claudio Imbrenda
2025-10-29 16:32 ` Christian Borntraeger
2025-10-30  7:10 ` Thomas Huth
2025-10-31  8:45   ` Janosch Frank
2025-10-31  9:36     ` Thomas Huth

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).