From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: KVM <kvm@vger.kernel.org>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>,
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: [RFC PATCH] KVM: s390: move some facilities from FACILITIES_KVM_CPUMODEL to FACILITIES_KVM
Date: Wed, 1 Apr 2026 15:42:54 +0200 [thread overview]
Message-ID: <20260401134254.259873-1-borntraeger@linux.ibm.com> (raw)
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
reply other threads:[~2026-04-01 13:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260401134254.259873-1-borntraeger@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