* [PATCH] s390x: pv: Fence additional unavailable SCLP facilities for PV guests
@ 2020-12-04 8:36 Janosch Frank
2020-12-08 13:29 ` Christian Borntraeger
0 siblings, 1 reply; 6+ messages in thread
From: Janosch Frank @ 2020-12-04 8:36 UTC (permalink / raw)
To: qemu-devel; +Cc: borntraeger, qemu-s390x, cohuck, david
There's no VSIE support for a protected guest, so let's better not
advertise it and its support facilities.
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
---
CI:
https://gitlab.com/frankja/qemu/-/pipelines/224881703
---
target/s390x/cpu_features.c | 38 ++++++++++++++++++++++++++++++++++++-
target/s390x/cpu_models.c | 24 +++++++++++++++++++++--
2 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index 42fe0bf4ca..7d7ea8e3b8 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -107,8 +107,44 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
feat = find_next_bit(features, S390_FEAT_MAX, feat + 1);
}
- if (type == S390_FEAT_TYPE_SCLP_FAC134 && s390_is_pv()) {
+ if (!s390_is_pv()) {
+ return;
+ }
+
+ /*
+ * Some facilities are not available for CPUs in protected mode:
+ * - All SIE facilities because SIE is not available
+ * - DIAG318
+ *
+ * As VMs can move in and out of protected mode the CPU model
+ * doesn't protect us from that problem because it is only
+ * validated at the start of the VM.
+ */
+ switch (type) {
+ case S390_FEAT_TYPE_SCLP_CPU:
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_F2)->bit, data);
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_SKEY)->bit, data);
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_GPERE)->bit, data);
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_SIIF)->bit, data);
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_SIGPIF)->bit, data);
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_IB)->bit, data);
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_CEI)->bit, data);
+ break;
+ case S390_FEAT_TYPE_SCLP_CONF_CHAR:
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_KSS)->bit, data);
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_GSLS)->bit, data);
+ break;
+ case S390_FEAT_TYPE_SCLP_CONF_CHAR_EXT:
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_64BSCAO)->bit, data);
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_CMMA)->bit, data);
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_PFMFI)->bit, data);
+ clear_be_bit(s390_feat_def(S390_FEAT_SIE_IBS)->bit, data);
+ break;
+ case S390_FEAT_TYPE_SCLP_FAC134:
clear_be_bit(s390_feat_def(S390_FEAT_DIAG_318)->bit, data);
+ break;
+ default:
+ return;
}
}
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index b5abff8bef..51feb71546 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -239,8 +239,28 @@ bool s390_has_feat(S390Feat feat)
}
return 0;
}
- if (feat == S390_FEAT_DIAG_318 && s390_is_pv()) {
- return false;
+
+ if (s390_is_pv()) {
+ switch (feat) {
+ case S390_FEAT_DIAG_318:
+ case S390_FEAT_SIE_F2:
+ case S390_FEAT_SIE_SKEY:
+ case S390_FEAT_SIE_GPERE:
+ case S390_FEAT_SIE_SIIF:
+ case S390_FEAT_SIE_SIGPIF:
+ case S390_FEAT_SIE_IB:
+ case S390_FEAT_SIE_CEI:
+ case S390_FEAT_SIE_KSS:
+ case S390_FEAT_SIE_GSLS:
+ case S390_FEAT_SIE_64BSCAO:
+ case S390_FEAT_SIE_CMMA:
+ case S390_FEAT_SIE_PFMFI:
+ case S390_FEAT_SIE_IBS:
+ return false;
+ break;
+ default:
+ break;
+ }
}
return test_bit(feat, cpu->model->features);
}
--
2.25.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] s390x: pv: Fence additional unavailable SCLP facilities for PV guests
2020-12-04 8:36 [PATCH] s390x: pv: Fence additional unavailable SCLP facilities for PV guests Janosch Frank
@ 2020-12-08 13:29 ` Christian Borntraeger
2020-12-08 14:55 ` David Hildenbrand
0 siblings, 1 reply; 6+ messages in thread
From: Christian Borntraeger @ 2020-12-08 13:29 UTC (permalink / raw)
To: Janosch Frank, qemu-devel; +Cc: qemu-s390x, cohuck, david
On 04.12.20 09:36, Janosch Frank wrote:
> There's no VSIE support for a protected guest, so let's better not
> advertise it and its support facilities.
>
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Looks sane. Assuming that all features that depend on SIE are named S390_FEAT_SIE_*
this should take care of everything. (i compared to gen-facilities.c)
> ---
> CI:
> https://gitlab.com/frankja/qemu/-/pipelines/224881703
> ---
> target/s390x/cpu_features.c | 38 ++++++++++++++++++++++++++++++++++++-
> target/s390x/cpu_models.c | 24 +++++++++++++++++++++--
> 2 files changed, 59 insertions(+), 3 deletions(-)
>
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index 42fe0bf4ca..7d7ea8e3b8 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -107,8 +107,44 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
> feat = find_next_bit(features, S390_FEAT_MAX, feat + 1);
> }
>
> - if (type == S390_FEAT_TYPE_SCLP_FAC134 && s390_is_pv()) {
> + if (!s390_is_pv()) {
> + return;
> + }
> +
> + /*
> + * Some facilities are not available for CPUs in protected mode:
> + * - All SIE facilities because SIE is not available
> + * - DIAG318
> + *
> + * As VMs can move in and out of protected mode the CPU model
> + * doesn't protect us from that problem because it is only
> + * validated at the start of the VM.
> + */
> + switch (type) {
> + case S390_FEAT_TYPE_SCLP_CPU:
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_F2)->bit, data);
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_SKEY)->bit, data);
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_GPERE)->bit, data);
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_SIIF)->bit, data);
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_SIGPIF)->bit, data);
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_IB)->bit, data);
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_CEI)->bit, data);
> + break;
> + case S390_FEAT_TYPE_SCLP_CONF_CHAR:
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_KSS)->bit, data);
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_GSLS)->bit, data);
> + break;
> + case S390_FEAT_TYPE_SCLP_CONF_CHAR_EXT:
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_64BSCAO)->bit, data);
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_CMMA)->bit, data);
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_PFMFI)->bit, data);
> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_IBS)->bit, data);
> + break;
> + case S390_FEAT_TYPE_SCLP_FAC134:
> clear_be_bit(s390_feat_def(S390_FEAT_DIAG_318)->bit, data);
> + break;
> + default:
> + return;
> }
> }
>
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index b5abff8bef..51feb71546 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -239,8 +239,28 @@ bool s390_has_feat(S390Feat feat)
> }
> return 0;
> }
> - if (feat == S390_FEAT_DIAG_318 && s390_is_pv()) {
> - return false;
> +
> + if (s390_is_pv()) {
> + switch (feat) {
> + case S390_FEAT_DIAG_318:
> + case S390_FEAT_SIE_F2:
> + case S390_FEAT_SIE_SKEY:
> + case S390_FEAT_SIE_GPERE:
> + case S390_FEAT_SIE_SIIF:
> + case S390_FEAT_SIE_SIGPIF:
> + case S390_FEAT_SIE_IB:
> + case S390_FEAT_SIE_CEI:
> + case S390_FEAT_SIE_KSS:
> + case S390_FEAT_SIE_GSLS:
> + case S390_FEAT_SIE_64BSCAO:
> + case S390_FEAT_SIE_CMMA:
> + case S390_FEAT_SIE_PFMFI:
> + case S390_FEAT_SIE_IBS:
> + return false;
> + break;
> + default:
> + break;
> + }
> }
> return test_bit(feat, cpu->model->features);
> }
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] s390x: pv: Fence additional unavailable SCLP facilities for PV guests
2020-12-08 13:29 ` Christian Borntraeger
@ 2020-12-08 14:55 ` David Hildenbrand
2020-12-08 16:11 ` Christian Borntraeger
0 siblings, 1 reply; 6+ messages in thread
From: David Hildenbrand @ 2020-12-08 14:55 UTC (permalink / raw)
To: Christian Borntraeger, Janosch Frank, qemu-devel; +Cc: qemu-s390x, cohuck
On 08.12.20 14:29, Christian Borntraeger wrote:
>
>
> On 04.12.20 09:36, Janosch Frank wrote:
>> There's no VSIE support for a protected guest, so let's better not
>> advertise it and its support facilities.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>
> Looks sane. Assuming that all features that depend on SIE are named S390_FEAT_SIE_*
> this should take care of everything. (i compared to gen-facilities.c)
We could add dependency checks to
target/s390x/cpu_models.c:check_consistency()
What about
DEF_FEAT(ESOP, "esop", SCLP_CONF_CHAR, 46,
"Enhanced-suppression-on-protection facility")
DEF_FEAT(HPMA2, "hpma2", SCLP_CONF_CHAR, 90, "Host page management
assist 2 Facility")
Although not related so SIE, do these features make sense for protected
guests?
>
>> ---
>> CI:
>> https://gitlab.com/frankja/qemu/-/pipelines/224881703
>> ---
>> target/s390x/cpu_features.c | 38 ++++++++++++++++++++++++++++++++++++-
>> target/s390x/cpu_models.c | 24 +++++++++++++++++++++--
>> 2 files changed, 59 insertions(+), 3 deletions(-)
>>
>> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
>> index 42fe0bf4ca..7d7ea8e3b8 100644
>> --- a/target/s390x/cpu_features.c
>> +++ b/target/s390x/cpu_features.c
>> @@ -107,8 +107,44 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
>> feat = find_next_bit(features, S390_FEAT_MAX, feat + 1);
>> }
>>
>> - if (type == S390_FEAT_TYPE_SCLP_FAC134 && s390_is_pv()) {
>> + if (!s390_is_pv()) {
>> + return;
>> + }
>> +
>> + /*
>> + * Some facilities are not available for CPUs in protected mode:
>> + * - All SIE facilities because SIE is not available
>> + * - DIAG318
>> + *
>> + * As VMs can move in and out of protected mode the CPU model
>> + * doesn't protect us from that problem because it is only
>> + * validated at the start of the VM.
>> + */
>> + switch (type) {
>> + case S390_FEAT_TYPE_SCLP_CPU:
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_F2)->bit, data);
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_SKEY)->bit, data);
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_GPERE)->bit, data);
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_SIIF)->bit, data);
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_SIGPIF)->bit, data);
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_IB)->bit, data);
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_CEI)->bit, data);
>> + break;
>> + case S390_FEAT_TYPE_SCLP_CONF_CHAR:
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_KSS)->bit, data);
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_GSLS)->bit, data);
>> + break;
>> + case S390_FEAT_TYPE_SCLP_CONF_CHAR_EXT:
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_64BSCAO)->bit, data);
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_CMMA)->bit, data);
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_PFMFI)->bit, data);
>> + clear_be_bit(s390_feat_def(S390_FEAT_SIE_IBS)->bit, data);
>> + break;
>> + case S390_FEAT_TYPE_SCLP_FAC134:
>> clear_be_bit(s390_feat_def(S390_FEAT_DIAG_318)->bit, data);
>> + break;
>> + default:
>> + return;
>> }
>> }
>>
>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>> index b5abff8bef..51feb71546 100644
>> --- a/target/s390x/cpu_models.c
>> +++ b/target/s390x/cpu_models.c
>> @@ -239,8 +239,28 @@ bool s390_has_feat(S390Feat feat)
>> }
>> return 0;
>> }
>> - if (feat == S390_FEAT_DIAG_318 && s390_is_pv()) {
>> - return false;
>> +
>> + if (s390_is_pv()) {
>> + switch (feat) {
>> + case S390_FEAT_DIAG_318:
>> + case S390_FEAT_SIE_F2:
>> + case S390_FEAT_SIE_SKEY:
>> + case S390_FEAT_SIE_GPERE:
>> + case S390_FEAT_SIE_SIIF:
>> + case S390_FEAT_SIE_SIGPIF:
>> + case S390_FEAT_SIE_IB:
>> + case S390_FEAT_SIE_CEI:
>> + case S390_FEAT_SIE_KSS:
>> + case S390_FEAT_SIE_GSLS:
>> + case S390_FEAT_SIE_64BSCAO:
>> + case S390_FEAT_SIE_CMMA:
>> + case S390_FEAT_SIE_PFMFI:
>> + case S390_FEAT_SIE_IBS:
>> + return false;
>> + break;
>> + default:
>> + break;
>> + }
>> }
>> return test_bit(feat, cpu->model->features);
>> }
>>
>
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] s390x: pv: Fence additional unavailable SCLP facilities for PV guests
2020-12-08 14:55 ` David Hildenbrand
@ 2020-12-08 16:11 ` Christian Borntraeger
2020-12-08 16:19 ` David Hildenbrand
0 siblings, 1 reply; 6+ messages in thread
From: Christian Borntraeger @ 2020-12-08 16:11 UTC (permalink / raw)
To: David Hildenbrand, Janosch Frank, qemu-devel; +Cc: qemu-s390x, cohuck
On 08.12.20 15:55, David Hildenbrand wrote:
> On 08.12.20 14:29, Christian Borntraeger wrote:
>>
>>
>> On 04.12.20 09:36, Janosch Frank wrote:
>>> There's no VSIE support for a protected guest, so let's better not
>>> advertise it and its support facilities.
>>>
>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>>
>> Looks sane. Assuming that all features that depend on SIE are named S390_FEAT_SIE_*
>> this should take care of everything. (i compared to gen-facilities.c)
>
> We could add dependency checks to
> target/s390x/cpu_models.c:check_consistency()
That could be an additional patch, right?
>
> What about
>
> DEF_FEAT(ESOP, "esop", SCLP_CONF_CHAR, 46,
> "Enhanced-suppression-on-protection facility")
ESOP does make sense independent from SIE see chapter 3-15 in the POP
in "Suppression on Protection"
> DEF_FEAT(HPMA2, "hpma2", SCLP_CONF_CHAR, 90, "Host page management
> assist 2 Facility")
Right. We should also fence of hpma2.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] s390x: pv: Fence additional unavailable SCLP facilities for PV guests
2020-12-08 16:11 ` Christian Borntraeger
@ 2020-12-08 16:19 ` David Hildenbrand
2020-12-09 8:54 ` Janosch Frank
0 siblings, 1 reply; 6+ messages in thread
From: David Hildenbrand @ 2020-12-08 16:19 UTC (permalink / raw)
To: Christian Borntraeger, Janosch Frank, qemu-devel; +Cc: qemu-s390x, cohuck
On 08.12.20 17:11, Christian Borntraeger wrote:
>
>
> On 08.12.20 15:55, David Hildenbrand wrote:
>> On 08.12.20 14:29, Christian Borntraeger wrote:
>>>
>>>
>>> On 04.12.20 09:36, Janosch Frank wrote:
>>>> There's no VSIE support for a protected guest, so let's better not
>>>> advertise it and its support facilities.
>>>>
>>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>>>
>>> Looks sane. Assuming that all features that depend on SIE are named S390_FEAT_SIE_*
>>> this should take care of everything. (i compared to gen-facilities.c)
>>
>> We could add dependency checks to
>> target/s390x/cpu_models.c:check_consistency()
>
> That could be an additional patch, right?
Yeah sure.
>
>>
>> What about
>>
>> DEF_FEAT(ESOP, "esop", SCLP_CONF_CHAR, 46,
>> "Enhanced-suppression-on-protection facility")
>
> ESOP does make sense independent from SIE see chapter 3-15 in the POP
> in "Suppression on Protection"
>
Rings a bell :)
>
>> DEF_FEAT(HPMA2, "hpma2", SCLP_CONF_CHAR, 90, "Host page management
>> assist 2 Facility")
>
> Right. We should also fence of hpma2.
I was also wondering about CMM, but as the guest senses it by executing
the instruction, protected guests will never see it I assume.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] s390x: pv: Fence additional unavailable SCLP facilities for PV guests
2020-12-08 16:19 ` David Hildenbrand
@ 2020-12-09 8:54 ` Janosch Frank
0 siblings, 0 replies; 6+ messages in thread
From: Janosch Frank @ 2020-12-09 8:54 UTC (permalink / raw)
To: David Hildenbrand, Christian Borntraeger, qemu-devel; +Cc: qemu-s390x, cohuck
On 12/8/20 5:19 PM, David Hildenbrand wrote:
> On 08.12.20 17:11, Christian Borntraeger wrote:
>>
>>
>> On 08.12.20 15:55, David Hildenbrand wrote:
>>> On 08.12.20 14:29, Christian Borntraeger wrote:
>>>>
>>>>
>>>> On 04.12.20 09:36, Janosch Frank wrote:
>>>>> There's no VSIE support for a protected guest, so let's better not
>>>>> advertise it and its support facilities.
>>>>>
>>>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>>>>
>>>> Looks sane. Assuming that all features that depend on SIE are named S390_FEAT_SIE_*
>>>> this should take care of everything. (i compared to gen-facilities.c)
>>>
>>> We could add dependency checks to
>>> target/s390x/cpu_models.c:check_consistency()
>>
>> That could be an additional patch, right?
>
> Yeah sure.
>
>>
>>>
>>> What about
>>>
>>> DEF_FEAT(ESOP, "esop", SCLP_CONF_CHAR, 46,
>>> "Enhanced-suppression-on-protection facility")
>>
>> ESOP does make sense independent from SIE see chapter 3-15 in the POP
>> in "Suppression on Protection"
>>
>
> Rings a bell :)
>
>>
>>> DEF_FEAT(HPMA2, "hpma2", SCLP_CONF_CHAR, 90, "Host page management
>>> assist 2 Facility")
>>
>> Right. We should also fence of hpma2.
>
> I was also wondering about CMM, but as the guest senses it by executing
> the instruction, protected guests will never see it I assume.
>
Yep, it's a operation exception.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-12-09 9:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-12-04 8:36 [PATCH] s390x: pv: Fence additional unavailable SCLP facilities for PV guests Janosch Frank
2020-12-08 13:29 ` Christian Borntraeger
2020-12-08 14:55 ` David Hildenbrand
2020-12-08 16:11 ` Christian Borntraeger
2020-12-08 16:19 ` David Hildenbrand
2020-12-09 8:54 ` Janosch Frank
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).