[RFC PATCH] KVM: s390: move some facilities from FACILITIES_KVM_CPUMODEL to FACILITIES_KVM

[RFC PATCH] KVM: s390: move some facilities from FACILITIES_KVM_CPUMODEL to FACILITIES_KVM

[Christian Borntraeger]

Some facilities have been put into FACILITIES_KVM_CPUMODEL to be on the
safe side with older VMMs. Unfortunately this has some unwanted side
effects for VMMs without a CPU model (like kvm unit test) and IBC/VAL is
not used in that case.

Ideally the guest visible STFLE bits, the behaviour when running
interpreted (HW supported) and the behaviour when running emulated (kvm
or qemu) should be in sync.

For LPSWEY this was not the case. STFLE.193 was off, but interpretion
did work, emulation did not. As emulation only happened in rare cases
(e.g. deliver a machine check) the result was inconsistency for the
guest.
Move beareh to FACILITIES_KVM to fix the inconsistency.

NNPA (facility 165) has no fencing and no KVM emulation. The instruction
will work, despite STFLE.165 being off in the guest. Move also to
FACILITIES_KVM.

Facility 170 (ineffective-nonconstrained-transaction facility) is an
anti facility and should be passed along as well as KVM cannot simulate
the missing function.

KVM also does not implement trapping for guest RDP and there is no
additional hypervisor control. Move 194 to FACILITIES_KVM as well.

Facilities 196 and 197 (PAI) also do not have a hypervisor control and
need to be passed on as well.

The PFCR is also not intercepted by KVM and needs to be moved (stfle.201).

The other facilities are fine (stfle, emulation, interpretion in sync):
Both AP related features (12 and 15) require a userspace added AP via vfio.
156 etoken facility is fenced off for interpretion via ECD_ETOKENF so
everything is in sync

Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
Cc: Janosch Frank <frankja@linux.ibm.com>
---
 arch/s390/tools/gen_facilities.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index 2d28a569f793..32dd5a57240d 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -96,6 +96,13 @@ static struct facility_def facility_defs[] = {
 			150, /* enhanced sort */
 			151, /* deflate conversion */
 			155, /* msa extension 9 */
+			165, /* nnpa facility */
+			170, /* ineffective-nonconstrained-transaction facility */
+			193, /* bear enhancement facility */
+			194, /* rdp enhancement facility */
+			196, /* processor activity instrumentation facility */
+			197, /* processor activity instrumentation extension 1 */
+			201, /* concurrent-functions facility */
 			-1  /* END */
 		}
 	},
@@ -112,13 +119,6 @@ static struct facility_def facility_defs[] = {
 			12, /* AP Query Configuration Information */
 			15, /* AP Facilities Test */
 			156, /* etoken facility */
-			165, /* nnpa facility */
-			170, /* ineffective-nonconstrained-transaction facility */
-			193, /* bear enhancement facility */
-			194, /* rdp enhancement facility */
-			196, /* processor activity instrumentation facility */
-			197, /* processor activity instrumentation extension 1 */
-			201, /* concurrent-functions facility */
 			-1  /* END */
 		}
 	},
-- 
2.53.0

Re: [RFC PATCH] KVM: s390: move some facilities from FACILITIES_KVM_CPUMODEL to FACILITIES_KVM

[Christian Borntraeger]

Am 01.04.26 um 15:42 schrieb Christian Borntraeger:
> Some facilities have been put into FACILITIES_KVM_CPUMODEL to be on the
> safe side with older VMMs. Unfortunately this has some unwanted side
> effects for VMMs without a CPU model (like kvm unit test) and IBC/VAL is
> not used in that case.
> 
> Ideally the guest visible STFLE bits, the behaviour when running
> interpreted (HW supported) and the behaviour when running emulated (kvm
> or qemu) should be in sync.
> 
> For LPSWEY this was not the case. STFLE.193 was off, but interpretion
> did work, emulation did not. As emulation only happened in rare cases
> (e.g. deliver a machine check) the result was inconsistency for the
> guest.
> Move beareh to FACILITIES_KVM to fix the inconsistency.
> 
> NNPA (facility 165) has no fencing and no KVM emulation. The instruction
> will work, despite STFLE.165 being off in the guest. Move also to
> FACILITIES_KVM.
> 
> Facility 170 (ineffective-nonconstrained-transaction facility) is an
> anti facility and should be passed along as well as KVM cannot simulate
> the missing function.
> 
> KVM also does not implement trapping for guest RDP and there is no
> additional hypervisor control. Move 194 to FACILITIES_KVM as well.
> 
> Facilities 196 and 197 (PAI) also do not have a hypervisor control and
> need to be passed on as well.
> 
> The PFCR is also not intercepted by KVM and needs to be moved (stfle.201).
> 
> The other facilities are fine (stfle, emulation, interpretion in sync):
> Both AP related features (12 and 15) require a userspace added AP via vfio.
> 156 etoken facility is fenced off for interpretion via ECD_ETOKENF so
> everything is in sync
> 
> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
> Cc: Janosch Frank <frankja@linux.ibm.com>


ping.  Any concerns?

> ---
>   arch/s390/tools/gen_facilities.c | 14 +++++++-------
>   1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
> index 2d28a569f793..32dd5a57240d 100644
> --- a/arch/s390/tools/gen_facilities.c
> +++ b/arch/s390/tools/gen_facilities.c
> @@ -96,6 +96,13 @@ static struct facility_def facility_defs[] = {
>   			150, /* enhanced sort */
>   			151, /* deflate conversion */
>   			155, /* msa extension 9 */
> +			165, /* nnpa facility */
> +			170, /* ineffective-nonconstrained-transaction facility */
> +			193, /* bear enhancement facility */
> +			194, /* rdp enhancement facility */
> +			196, /* processor activity instrumentation facility */
> +			197, /* processor activity instrumentation extension 1 */
> +			201, /* concurrent-functions facility */
>   			-1  /* END */
>   		}
>   	},
> @@ -112,13 +119,6 @@ static struct facility_def facility_defs[] = {
>   			12, /* AP Query Configuration Information */
>   			15, /* AP Facilities Test */
>   			156, /* etoken facility */
> -			165, /* nnpa facility */
> -			170, /* ineffective-nonconstrained-transaction facility */
> -			193, /* bear enhancement facility */
> -			194, /* rdp enhancement facility */
> -			196, /* processor activity instrumentation facility */
> -			197, /* processor activity instrumentation extension 1 */
> -			201, /* concurrent-functions facility */
>   			-1  /* END */
>   		}
>   	},

Re: [RFC PATCH] KVM: s390: move some facilities from FACILITIES_KVM_CPUMODEL to FACILITIES_KVM

[Janosch Frank]

On 4/17/26 11:00, Christian Borntraeger wrote:
> Am 01.04.26 um 15:42 schrieb Christian Borntraeger:
>> Some facilities have been put into FACILITIES_KVM_CPUMODEL to be on the
>> safe side with older VMMs. Unfortunately this has some unwanted side
>> effects for VMMs without a CPU model (like kvm unit test) and IBC/VAL is
>> not used in that case.
>>
>> Ideally the guest visible STFLE bits, the behaviour when running
>> interpreted (HW supported) and the behaviour when running emulated (kvm
>> or qemu) should be in sync.
>>
>> For LPSWEY this was not the case. STFLE.193 was off, but interpretion
>> did work, emulation did not. As emulation only happened in rare cases
>> (e.g. deliver a machine check) the result was inconsistency for the
>> guest.
>> Move beareh to FACILITIES_KVM to fix the inconsistency.
>>
>> NNPA (facility 165) has no fencing and no KVM emulation. The instruction
>> will work, despite STFLE.165 being off in the guest. Move also to
>> FACILITIES_KVM.
>>
>> Facility 170 (ineffective-nonconstrained-transaction facility) is an
>> anti facility and should be passed along as well as KVM cannot simulate
>> the missing function.
>>
>> KVM also does not implement trapping for guest RDP and there is no
>> additional hypervisor control. Move 194 to FACILITIES_KVM as well.
>>
>> Facilities 196 and 197 (PAI) also do not have a hypervisor control and
>> need to be passed on as well.
>>
>> The PFCR is also not intercepted by KVM and needs to be moved (stfle.201).
>>
>> The other facilities are fine (stfle, emulation, interpretion in sync):
>> Both AP related features (12 and 15) require a userspace added AP via vfio.
>> 156 etoken facility is fenced off for interpretion via ECD_ETOKENF so
>> everything is in sync
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
>> Cc: David Hildenbrand <david@kernel.org>
>> Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
>> Cc: Janosch Frank <frankja@linux.ibm.com>
> 
> 
> ping.  Any concerns?

Ah, this fell to the floor because of other things. Sorry

Makes sense to me:
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>