[PATCH v2 0/3] KVM: s390: Toggle operation exception for userspace

[PATCH v2 0/3] KVM: s390: Toggle operation exception for userspace

[Eric Farman]

Claudio, et al,

Here's an update to the USER_OPEREXEC patch I'd sent the other day.
Besides the addition of Claudio's r-b (thank you!), Patch 1 is identical.

Patch 2 contains a couple of new selftests. As it stands, they all run
with patch 1 applied, but I put the failing test at the end for if
Patch 1 is missing.

Patch 3 is unrelated, but is a minor typo I stumbled on yesterday while
looking at this. It seems small enough that a second `git send-email`
command seems unnecessary. :)

Eric Farman (3):
  KVM: s390: Toggle operation exception for userspace
  KVM: s390: selftests: Extended user_operexec tests
  KVM: s390: Fix typo in UCONTROL documentation

 Documentation/virt/kvm/api.rst                |   2 +-
 arch/s390/kvm/kvm-s390.c                      |   3 +-
 .../selftests/kvm/include/s390/facility.h     |   6 +
 .../selftests/kvm/s390/user_operexec.c        | 110 ++++++++++++++++++
 4 files changed, 119 insertions(+), 2 deletions(-)

-- 
2.51.0

[PATCH v2 1/3] KVM: s390: Toggle operation exception for userspace

[Eric Farman]

The KVM_CAP_S390_USER_OPEREXEC capability allows operation exceptions
to be forwarded to userspace. But the actual enablement at the hardware
level occurs in kvm_arch_vcpu_postcreate(), and only if STFLE.74 or
user_instr0 are enabled. The latter is associated with a separate
capability (KVM_CAP_S390_USER_INSTR0), so the only way this happens
for the USER_OPEREXEC capability is if STFLE.74 is enabled. KVM
unconditionally enables this bit in kvm_arch_init_vm(), but the guest
could disable it from the CPU model and thus ignore this capability.

Add USER_OPEREXEC to the check in kvm_arch_vcpu_postcreate(), such that
either capability would enable this type of exception.

Fixes: 8e8678e740ec ("KVM: s390: Add capability that forwards operation exceptions")
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Signed-off-by: Eric Farman <farman@linux.ibm.com>
---
 arch/s390/kvm/kvm-s390.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index e09960c2e6ed..a91a42174302 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -3521,7 +3521,8 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
 		vcpu->arch.gmap = vcpu->kvm->arch.gmap;
 		sca_add_vcpu(vcpu);
 	}
-	if (test_kvm_facility(vcpu->kvm, 74) || vcpu->kvm->arch.user_instr0)
+	if (test_kvm_facility(vcpu->kvm, 74) || vcpu->kvm->arch.user_instr0 ||
+	    vcpu->kvm->arch.user_operexec)
 		vcpu->arch.sie_block->ictl |= ICTL_OPEREXC;
 }
 
-- 
2.51.0

Re: [PATCH v2 1/3] KVM: s390: Toggle operation exception for userspace

[Christian Borntraeger]

Am 07.05.26 um 22:08 schrieb Eric Farman:
> The KVM_CAP_S390_USER_OPEREXEC capability allows operation exceptions
> to be forwarded to userspace. But the actual enablement at the hardware
> level occurs in kvm_arch_vcpu_postcreate(), and only if STFLE.74 or
> user_instr0 are enabled. The latter is associated with a separate
> capability (KVM_CAP_S390_USER_INSTR0), so the only way this happens
> for the USER_OPEREXEC capability is if STFLE.74 is enabled. KVM
> unconditionally enables this bit in kvm_arch_init_vm(), but the guest
> could disable it from the CPU model and thus ignore this capability.
> 
> Add USER_OPEREXEC to the check in kvm_arch_vcpu_postcreate(), such that
> either capability would enable this type of exception.
> 
> Fixes: 8e8678e740ec ("KVM: s390: Add capability that forwards operation exceptions")
> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Signed-off-by: Eric Farman <farman@linux.ibm.com>

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


> ---
>   arch/s390/kvm/kvm-s390.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index e09960c2e6ed..a91a42174302 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -3521,7 +3521,8 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
>   		vcpu->arch.gmap = vcpu->kvm->arch.gmap;
>   		sca_add_vcpu(vcpu);
>   	}
> -	if (test_kvm_facility(vcpu->kvm, 74) || vcpu->kvm->arch.user_instr0)
> +	if (test_kvm_facility(vcpu->kvm, 74) || vcpu->kvm->arch.user_instr0 ||
> +	    vcpu->kvm->arch.user_operexec)
>   		vcpu->arch.sie_block->ictl |= ICTL_OPEREXC;
>   }
>   

Re: [PATCH v2 1/3] KVM: s390: Toggle operation exception for userspace

[Janosch Frank]

On 5/7/26 22:08, Eric Farman wrote:
> The KVM_CAP_S390_USER_OPEREXEC capability allows operation exceptions
> to be forwarded to userspace. But the actual enablement at the hardware
> level occurs in kvm_arch_vcpu_postcreate(), and only if STFLE.74 or
> user_instr0 are enabled. The latter is associated with a separate
> capability (KVM_CAP_S390_USER_INSTR0), so the only way this happens
> for the USER_OPEREXEC capability is if STFLE.74 is enabled. KVM
> unconditionally enables this bit in kvm_arch_init_vm(), but the guest
> could disable it from the CPU model and thus ignore this capability.
> 
> Add USER_OPEREXEC to the check in kvm_arch_vcpu_postcreate(), such that
> either capability would enable this type of exception.
> 
> Fixes: 8e8678e740ec ("KVM: s390: Add capability that forwards operation exceptions")
> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Signed-off-by: Eric Farman <farman@linux.ibm.com>

It boggles my mind that I missed this, sigh

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

> ---
>   arch/s390/kvm/kvm-s390.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index e09960c2e6ed..a91a42174302 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -3521,7 +3521,8 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
>   		vcpu->arch.gmap = vcpu->kvm->arch.gmap;
>   		sca_add_vcpu(vcpu);
>   	}
> -	if (test_kvm_facility(vcpu->kvm, 74) || vcpu->kvm->arch.user_instr0)
> +	if (test_kvm_facility(vcpu->kvm, 74) || vcpu->kvm->arch.user_instr0 ||
> +	    vcpu->kvm->arch.user_operexec)
>   		vcpu->arch.sie_block->ictl |= ICTL_OPEREXC;
>   }
>   

Re: [PATCH v2 1/3] KVM: s390: Toggle operation exception for userspace

[Janosch Frank]

On 5/7/26 22:08, Eric Farman wrote:
> The KVM_CAP_S390_USER_OPEREXEC capability allows operation exceptions
> to be forwarded to userspace. But the actual enablement at the hardware
> level occurs in kvm_arch_vcpu_postcreate(), and only if STFLE.74 or
> user_instr0 are enabled. The latter is associated with a separate
> capability (KVM_CAP_S390_USER_INSTR0), so the only way this happens
> for the USER_OPEREXEC capability is if STFLE.74 is enabled. KVM
> unconditionally enables this bit in kvm_arch_init_vm(), but the guest
> could disable it from the CPU model and thus ignore this capability.
> 
> Add USER_OPEREXEC to the check in kvm_arch_vcpu_postcreate(), such that
> either capability would enable this type of exception.
> 

Naming wise shouldn't this be something like:
KVM: s390: Fix S390_USER_OPEREXEC enablement without stfle 74

?

Re: [PATCH v2 1/3] KVM: s390: Toggle operation exception for userspace

[Eric Farman]

On Mon, 2026-05-11 at 10:08 +0200, Janosch Frank wrote:
> On 5/7/26 22:08, Eric Farman wrote:
> > The KVM_CAP_S390_USER_OPEREXEC capability allows operation exceptions
> > to be forwarded to userspace. But the actual enablement at the hardware
> > level occurs in kvm_arch_vcpu_postcreate(), and only if STFLE.74 or
> > user_instr0 are enabled. The latter is associated with a separate
> > capability (KVM_CAP_S390_USER_INSTR0), so the only way this happens
> > for the USER_OPEREXEC capability is if STFLE.74 is enabled. KVM
> > unconditionally enables this bit in kvm_arch_init_vm(), but the guest
> > could disable it from the CPU model and thus ignore this capability.
> > 
> > Add USER_OPEREXEC to the check in kvm_arch_vcpu_postcreate(), such that
> > either capability would enable this type of exception.
> > 
> 
> Naming wise shouldn't this be something like:
> KVM: s390: Fix S390_USER_OPEREXEC enablement without stfle 74
> 
> ?

Yeah, that is clearer, and I would be fine with that edit.

[PATCH v2 2/3] KVM: s390: selftests: Extended user_operexec tests

[Eric Farman]

There is a possibility that the user_operexec capability
only works if facility bit 74 is enabled. This is now fixed,
but add a selftest to demonstrate that.

Signed-off-by: Eric Farman <farman@linux.ibm.com>
---
 .../selftests/kvm/include/s390/facility.h     |   6 +
 .../selftests/kvm/s390/user_operexec.c        | 110 ++++++++++++++++++
 2 files changed, 116 insertions(+)

diff --git a/tools/testing/selftests/kvm/include/s390/facility.h b/tools/testing/selftests/kvm/include/s390/facility.h
index 41a265742666..e5259f63be22 100644
--- a/tools/testing/selftests/kvm/include/s390/facility.h
+++ b/tools/testing/selftests/kvm/include/s390/facility.h
@@ -11,6 +11,7 @@
 #ifndef SELFTEST_KVM_FACILITY_H
 #define SELFTEST_KVM_FACILITY_H
 
+#include <linux/atomic.h>
 #include <linux/bitops.h>
 
 /* alt_stfle_fac_list[16] + stfle_fac_list[16] */
@@ -19,6 +20,11 @@
 extern u64 stfl_doublewords[NB_STFL_DOUBLEWORDS];
 extern bool stfle_flag;
 
+static inline bool clear_bit_inv(unsigned long nr, unsigned long *ptr)
+{
+	return clear_bit(nr ^ (BITS_PER_LONG - 1), ptr);
+}
+
 static inline bool test_bit_inv(unsigned long nr, const unsigned long *ptr)
 {
 	return test_bit(nr ^ (BITS_PER_LONG - 1), ptr);
diff --git a/tools/testing/selftests/kvm/s390/user_operexec.c b/tools/testing/selftests/kvm/s390/user_operexec.c
index 714906c1d12a..b24c1f9dbbe8 100644
--- a/tools/testing/selftests/kvm/s390/user_operexec.c
+++ b/tools/testing/selftests/kvm/s390/user_operexec.c
@@ -6,6 +6,7 @@
  * Authors:
  *  Janosch Frank <frankja@linux.ibm.com>
  */
+#include "facility.h"
 #include "kselftest.h"
 #include "kvm_util.h"
 #include "test_util.h"
@@ -109,6 +110,111 @@ static void test_user_operexec_combined(void)
 	kvm_vm_free(vm);
 }
 
+static struct kvm_vm *create_vm_without_sthyi(void)
+{
+	struct kvm_s390_vm_cpu_processor info;
+	struct kvm_vm *vm;
+
+	vm = vm_create(1);
+
+	kvm_device_attr_get(vm->fd, KVM_S390_VM_CPU_MODEL,
+			    KVM_S390_VM_CPU_PROCESSOR, &info);
+
+	clear_bit_inv(74, (unsigned long *)&info.fac_list);
+	kvm_device_attr_set(vm->fd, KVM_S390_VM_CPU_MODEL,
+			    KVM_S390_VM_CPU_PROCESSOR, &info);
+
+	return vm;
+}
+
+static void test_user_instr0_no_stfle_74(void)
+{
+	struct kvm_vcpu *vcpu;
+	struct kvm_vm *vm;
+	int rc;
+
+	vm = create_vm_without_sthyi();
+
+	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
+	TEST_ASSERT_EQ(0, rc);
+
+	vcpu = vm_vcpu_add(vm, 0, guest_code_instr0);
+
+	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, 0x0000);
+
+	kvm_vm_free(vm);
+}
+
+static void test_user_operexec_no_stfle_74(void)
+{
+	struct kvm_vcpu *vcpu;
+	struct kvm_vm *vm;
+	int rc;
+
+	vm = create_vm_without_sthyi();
+
+	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
+	TEST_ASSERT_EQ(0, rc);
+
+	vcpu = vm_vcpu_add(vm, 0, guest_code_user_operexec);
+
+	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);
+}
+
+static void test_instr0_combined_no_stfle_74(void)
+{
+	struct kvm_vcpu *vcpu;
+	struct kvm_vm *vm;
+	int rc;
+
+	vm = create_vm_without_sthyi();
+
+	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 = vm_vcpu_add(vm, 0, guest_code_instr0);
+
+	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, 0x0000);
+
+	kvm_vm_free(vm);
+}
+
+static void test_operexec_combined_no_stfle_74(void)
+{
+	struct kvm_vcpu *vcpu;
+	struct kvm_vm *vm;
+	int rc;
+
+	vm = create_vm_without_sthyi();
+
+	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 = vm_vcpu_add(vm, 0, guest_code_user_operexec);
+
+	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.
  *
@@ -122,6 +228,10 @@ static struct testdef {
 	{ "instr0", test_user_instr0 },
 	{ "operexec", test_user_operexec },
 	{ "operexec_combined", test_user_operexec_combined},
+	{ "instr0_no_stfle_74", test_user_instr0_no_stfle_74 },
+	{ "instr0_combined_no_stfle_74", test_instr0_combined_no_stfle_74 },
+	{ "operexec_combined_no_stfle_74", test_operexec_combined_no_stfle_74 },
+	{ "operexec_no_stfle_74", test_user_operexec_no_stfle_74 },
 };
 
 int main(int argc, char *argv[])
-- 
2.51.0

Re: [PATCH v2 2/3] KVM: s390: selftests: Extended user_operexec tests

[Christian Borntraeger]

Am 07.05.26 um 22:08 schrieb Eric Farman:
> There is a possibility that the user_operexec capability
> only works if facility bit 74 is enabled. This is now fixed,
> but add a selftest to demonstrate that.
> 
> Signed-off-by: Eric Farman <farman@linux.ibm.com>

looks sane to me

Christian Borntraeger <borntraeger@linux.ibm.com>

Re: [PATCH v2 2/3] KVM: s390: selftests: Extended user_operexec tests

[Claudio Imbrenda]

On Thu,  7 May 2026 22:08:35 +0200
Eric Farman <farman@linux.ibm.com> wrote:

> There is a possibility that the user_operexec capability
> only works if facility bit 74 is enabled. This is now fixed,
> but add a selftest to demonstrate that.
> 
> Signed-off-by: Eric Farman <farman@linux.ibm.com>

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


> ---
>  .../selftests/kvm/include/s390/facility.h     |   6 +
>  .../selftests/kvm/s390/user_operexec.c        | 110 ++++++++++++++++++
>  2 files changed, 116 insertions(+)
> 
> diff --git a/tools/testing/selftests/kvm/include/s390/facility.h b/tools/testing/selftests/kvm/include/s390/facility.h
> index 41a265742666..e5259f63be22 100644
> --- a/tools/testing/selftests/kvm/include/s390/facility.h
> +++ b/tools/testing/selftests/kvm/include/s390/facility.h
> @@ -11,6 +11,7 @@
>  #ifndef SELFTEST_KVM_FACILITY_H
>  #define SELFTEST_KVM_FACILITY_H
>  
> +#include <linux/atomic.h>
>  #include <linux/bitops.h>
>  
>  /* alt_stfle_fac_list[16] + stfle_fac_list[16] */
> @@ -19,6 +20,11 @@
>  extern u64 stfl_doublewords[NB_STFL_DOUBLEWORDS];
>  extern bool stfle_flag;
>  
> +static inline bool clear_bit_inv(unsigned long nr, unsigned long *ptr)
> +{
> +	return clear_bit(nr ^ (BITS_PER_LONG - 1), ptr);
> +}
> +
>  static inline bool test_bit_inv(unsigned long nr, const unsigned long *ptr)
>  {
>  	return test_bit(nr ^ (BITS_PER_LONG - 1), ptr);
> diff --git a/tools/testing/selftests/kvm/s390/user_operexec.c b/tools/testing/selftests/kvm/s390/user_operexec.c
> index 714906c1d12a..b24c1f9dbbe8 100644
> --- a/tools/testing/selftests/kvm/s390/user_operexec.c
> +++ b/tools/testing/selftests/kvm/s390/user_operexec.c
> @@ -6,6 +6,7 @@
>   * Authors:
>   *  Janosch Frank <frankja@linux.ibm.com>
>   */
> +#include "facility.h"
>  #include "kselftest.h"
>  #include "kvm_util.h"
>  #include "test_util.h"
> @@ -109,6 +110,111 @@ static void test_user_operexec_combined(void)
>  	kvm_vm_free(vm);
>  }
>  
> +static struct kvm_vm *create_vm_without_sthyi(void)
> +{
> +	struct kvm_s390_vm_cpu_processor info;
> +	struct kvm_vm *vm;
> +
> +	vm = vm_create(1);
> +
> +	kvm_device_attr_get(vm->fd, KVM_S390_VM_CPU_MODEL,
> +			    KVM_S390_VM_CPU_PROCESSOR, &info);
> +
> +	clear_bit_inv(74, (unsigned long *)&info.fac_list);
> +	kvm_device_attr_set(vm->fd, KVM_S390_VM_CPU_MODEL,
> +			    KVM_S390_VM_CPU_PROCESSOR, &info);
> +
> +	return vm;
> +}
> +
> +static void test_user_instr0_no_stfle_74(void)
> +{
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	int rc;
> +
> +	vm = create_vm_without_sthyi();
> +
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_INSTR0, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu = vm_vcpu_add(vm, 0, guest_code_instr0);
> +
> +	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, 0x0000);
> +
> +	kvm_vm_free(vm);
> +}
> +
> +static void test_user_operexec_no_stfle_74(void)
> +{
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	int rc;
> +
> +	vm = create_vm_without_sthyi();
> +
> +	rc = __vm_enable_cap(vm, KVM_CAP_S390_USER_OPEREXEC, 0);
> +	TEST_ASSERT_EQ(0, rc);
> +
> +	vcpu = vm_vcpu_add(vm, 0, guest_code_user_operexec);
> +
> +	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);
> +}
> +
> +static void test_instr0_combined_no_stfle_74(void)
> +{
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	int rc;
> +
> +	vm = create_vm_without_sthyi();
> +
> +	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 = vm_vcpu_add(vm, 0, guest_code_instr0);
> +
> +	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, 0x0000);
> +
> +	kvm_vm_free(vm);
> +}
> +
> +static void test_operexec_combined_no_stfle_74(void)
> +{
> +	struct kvm_vcpu *vcpu;
> +	struct kvm_vm *vm;
> +	int rc;
> +
> +	vm = create_vm_without_sthyi();
> +
> +	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 = vm_vcpu_add(vm, 0, guest_code_user_operexec);
> +
> +	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.
>   *
> @@ -122,6 +228,10 @@ static struct testdef {
>  	{ "instr0", test_user_instr0 },
>  	{ "operexec", test_user_operexec },
>  	{ "operexec_combined", test_user_operexec_combined},
> +	{ "instr0_no_stfle_74", test_user_instr0_no_stfle_74 },
> +	{ "instr0_combined_no_stfle_74", test_instr0_combined_no_stfle_74 },
> +	{ "operexec_combined_no_stfle_74", test_operexec_combined_no_stfle_74 },
> +	{ "operexec_no_stfle_74", test_user_operexec_no_stfle_74 },
>  };
>  
>  int main(int argc, char *argv[])

Re: [PATCH v2 2/3] KVM: s390: selftests: Extended user_operexec tests

[Janosch Frank]

On 5/7/26 22:08, Eric Farman wrote:
> There is a possibility that the user_operexec capability
> only works if facility bit 74 is enabled. This is now fixed,
> but add a selftest to demonstrate that.

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

[PATCH v2 3/3] KVM: s390: Fix typo in UCONTROL documentation

[Eric Farman]

Small typo noticed while writing the USER_OPEREXEC selftest.

Signed-off-by: Eric Farman <farman@linux.ibm.com>
---
 Documentation/virt/kvm/api.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 52bbbb553ce1..f0eba90602f0 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6827,7 +6827,7 @@ s390 specific.
 		} s390_ucontrol;
 
 s390 specific. A page fault has occurred for a user controlled virtual
-machine (KVM_VM_S390_UNCONTROL) on its host page table that cannot be
+machine (KVM_VM_S390_UCONTROL) on its host page table that cannot be
 resolved by the kernel.
 The program code and the translation exception code that were placed
 in the cpu's lowcore are presented here as defined by the z Architecture
-- 
2.51.0

Re: [PATCH v2 3/3] KVM: s390: Fix typo in UCONTROL documentation

[Claudio Imbrenda]

On Thu,  7 May 2026 22:08:36 +0200
Eric Farman <farman@linux.ibm.com> wrote:

> Small typo noticed while writing the USER_OPEREXEC selftest.
> 
> Signed-off-by: Eric Farman <farman@linux.ibm.com>

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


> ---
>  Documentation/virt/kvm/api.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 52bbbb553ce1..f0eba90602f0 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6827,7 +6827,7 @@ s390 specific.
>  		} s390_ucontrol;
>  
>  s390 specific. A page fault has occurred for a user controlled virtual
> -machine (KVM_VM_S390_UNCONTROL) on its host page table that cannot be
> +machine (KVM_VM_S390_UCONTROL) on its host page table that cannot be
>  resolved by the kernel.
>  The program code and the translation exception code that were placed
>  in the cpu's lowcore are presented here as defined by the z Architecture

Re: [PATCH v2 3/3] KVM: s390: Fix typo in UCONTROL documentation

[Hendrik Brueckner]

On Thu, May 07, 2026 at 10:08:36PM +0200, Eric Farman wrote:
> Small typo noticed while writing the USER_OPEREXEC selftest.
> 
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
>  Documentation/virt/kvm/api.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>

Re: [PATCH v2 0/3] KVM: s390: Toggle operation exception for userspace

[Christian Borntraeger]

Am 07.05.26 um 22:08 schrieb Eric Farman:
> Claudio, et al,
> 
> Here's an update to the USER_OPEREXEC patch I'd sent the other day.
> Besides the addition of Claudio's r-b (thank you!), Patch 1 is identical.
> 
> Patch 2 contains a couple of new selftests. As it stands, they all run
> with patch 1 applied, but I put the failing test at the end for if
> Patch 1 is missing.
> 
> Patch 3 is unrelated, but is a minor typo I stumbled on yesterday while
> looking at this. It seems small enough that a second `git send-email`
> command seems unnecessary. :)
> 
> Eric Farman (3):
>    KVM: s390: Toggle operation exception for userspace
>    KVM: s390: selftests: Extended user_operexec tests
>    KVM: s390: Fix typo in UCONTROL documentation
> 
>   Documentation/virt/kvm/api.rst                |   2 +-
>   arch/s390/kvm/kvm-s390.c                      |   3 +-
>   .../selftests/kvm/include/s390/facility.h     |   6 +
>   .../selftests/kvm/s390/user_operexec.c        | 110 ++++++++++++++++++
>   4 files changed, 119 insertions(+), 2 deletions(-)
> 

Independent from this series (which makes sense on its own)
shouldnt we add another fixup so that we send these kernel injects also to userspace?


git grep PGM_OPERATION linux/master arch/s390/kvm/
linux/master:arch/s390/kvm/intercept.c:         return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
linux/master:arch/s390/kvm/intercept.c: return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
linux/master:arch/s390/kvm/priv.c:              return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
linux/master:arch/s390/kvm/priv.c:              return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
linux/master:arch/s390/kvm/priv.c:              return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
linux/master:arch/s390/kvm/priv.c:              return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
linux/master:arch/s390/kvm/priv.c:              return kvm_s390_inject_program_int(vcpu, PGM_OPERATION)

Re: [PATCH v2 0/3] KVM: s390: Toggle operation exception for userspace

[Eric Farman]

On Fri, 2026-05-08 at 12:07 +0200, Christian Borntraeger wrote:
> Am 07.05.26 um 22:08 schrieb Eric Farman:
> > Claudio, et al,
> > 
> > Here's an update to the USER_OPEREXEC patch I'd sent the other day.
> > Besides the addition of Claudio's r-b (thank you!), Patch 1 is identical.
> > 
> > Patch 2 contains a couple of new selftests. As it stands, they all run
> > with patch 1 applied, but I put the failing test at the end for if
> > Patch 1 is missing.
> > 
> > Patch 3 is unrelated, but is a minor typo I stumbled on yesterday while
> > looking at this. It seems small enough that a second `git send-email`
> > command seems unnecessary. :)
> > 
> > Eric Farman (3):
> >    KVM: s390: Toggle operation exception for userspace
> >    KVM: s390: selftests: Extended user_operexec tests
> >    KVM: s390: Fix typo in UCONTROL documentation
> > 
> >   Documentation/virt/kvm/api.rst                |   2 +-
> >   arch/s390/kvm/kvm-s390.c                      |   3 +-
> >   .../selftests/kvm/include/s390/facility.h     |   6 +
> >   .../selftests/kvm/s390/user_operexec.c        | 110 ++++++++++++++++++
> >   4 files changed, 119 insertions(+), 2 deletions(-)
> > 
> 
> Independent from this series (which makes sense on its own)
> shouldnt we add another fixup so that we send these kernel injects also to userspace?
> 

Hrm, that's a reasonable idea for the ones in priv.c (intercept.c are already covered, see below).
I'll see if I can find a way to unify (and test) them.

> 
> git grep PGM_OPERATION linux/master arch/s390/kvm/
> linux/master:arch/s390/kvm/intercept.c:         return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);

This is handle_sthyi(), called by handle_operexc(), if stfle.74 is not present.

> linux/master:arch/s390/kvm/intercept.c: return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);

This is handle_operexc(), if neither user_instr0 nor user_operexec are present.

> linux/master:arch/s390/kvm/priv.c:              return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
> linux/master:arch/s390/kvm/priv.c:              return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
> linux/master:arch/s390/kvm/priv.c:              return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
> linux/master:arch/s390/kvm/priv.c:              return kvm_s390_inject_program_int(vcpu, PGM_OPERATION);
> linux/master:arch/s390/kvm/priv.c:              return kvm_s390_inject_program_int(vcpu, PGM_OPERATION)

Re: [PATCH v2 0/3] KVM: s390: Toggle operation exception for userspace

[Christian Borntraeger]

Am 07.05.26 um 22:08 schrieb Eric Farman:
> Claudio, et al,
> 
> Here's an update to the USER_OPEREXEC patch I'd sent the other day.
> Besides the addition of Claudio's r-b (thank you!), Patch 1 is identical.
> 
> Patch 2 contains a couple of new selftests. As it stands, they all run
> with patch 1 applied, but I put the failing test at the end for if
> Patch 1 is missing.
> 
> Patch 3 is unrelated, but is a minor typo I stumbled on yesterday while
> looking at this. It seems small enough that a second `git send-email`
> command seems unnecessary. :)
> 
> Eric Farman (3):
>    KVM: s390: Toggle operation exception for userspace
>    KVM: s390: selftests: Extended user_operexec tests
>    KVM: s390: Fix typo in UCONTROL documentation
> 
>   Documentation/virt/kvm/api.rst                |   2 +-
>   arch/s390/kvm/kvm-s390.c                      |   3 +-
>   .../selftests/kvm/include/s390/facility.h     |   6 +
>   .../selftests/kvm/s390/user_operexec.c        | 110 ++++++++++++++++++
>   4 files changed, 119 insertions(+), 2 deletions(-)

I applied this series internally and queued for CI.