| Message ID | 20201204083655.27946-1-frankja@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | s390x: pv: Fence additional unavailable SCLP facilities for PV guests | expand |
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); > } >
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); >> } >> >
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.
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.
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.
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); }
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(-)