public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: KVM <kvm@vger.kernel.org>
Cc: Janosch Frank <frankja@linux.ibm.com>,
	David Hildenbrand <david@kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Hendrik Brueckner <brueckner@linux.ibm.com>
Subject: Re: [RFC PATCH] KVM: s390: move some facilities from FACILITIES_KVM_CPUMODEL to FACILITIES_KVM
Date: Fri, 17 Apr 2026 11:00:11 +0200	[thread overview]
Message-ID: <f92b3ea0-76d0-4393-8a82-18de3a7d3e08@linux.ibm.com> (raw)
In-Reply-To: <20260401134254.259873-1-borntraeger@linux.ibm.com>

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 */
>   		}
>   	},


  reply	other threads:[~2026-04-17  9:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-01 13:42 [RFC PATCH] KVM: s390: move some facilities from FACILITIES_KVM_CPUMODEL to FACILITIES_KVM Christian Borntraeger
2026-04-17  9:00 ` Christian Borntraeger [this message]
2026-04-17 12:02   ` Janosch Frank

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f92b3ea0-76d0-4393-8a82-18de3a7d3e08@linux.ibm.com \
    --to=borntraeger@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=brueckner@linux.ibm.com \
    --cc=david@kernel.org \
    --cc=frankja@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox