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

[Janosch Frank <frankja@linux.ibm.com>]

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>