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