| Message ID | 20201022082312.124708-1-frankja@linux.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | s390x: pv: Fix diag318 PV fencing | expand |
On 22.10.20 10:23, Janosch Frank wrote: > Diag318 fencing needs to be determined on the current VM PV state and > not on the state that the VM has when we create the CPU model. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> > Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> > Fixes: fabdada935 ("s390: guest support for diagnose 0x318") > --- > > If you're sure that this is what you want, then I'll send a v2 of the > patch set. So that's going to be the first CPU feature that gets suppressed in PC mode - which seems to be what we want. diag318_needed() will return false, resulting in vmstate_diag318() not being included in the migration stream (I know, we don't support migration yet for PV). I don't see where diag318 would get reset during a reipl - is it expected to be persistent when switching in/out of PV, or when reipling etc..? > > --- > target/s390x/cpu_features.c | 5 +++++ > target/s390x/cpu_features.h | 4 ++++ > target/s390x/cpu_models.c | 4 ++++ > target/s390x/kvm.c | 3 +-- > 4 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c > index 31ea8df246..42fe0bf4ca 100644 > --- a/target/s390x/cpu_features.c > +++ b/target/s390x/cpu_features.c > @@ -14,6 +14,7 @@ > #include "qemu/osdep.h" > #include "qemu/module.h" > #include "cpu_features.h" > +#include "hw/s390x/pv.h" > > #define DEF_FEAT(_FEAT, _NAME, _TYPE, _BIT, _DESC) \ > [S390_FEAT_##_FEAT] = { \ > @@ -105,6 +106,10 @@ 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()) { > + clear_be_bit(s390_feat_def(S390_FEAT_DIAG_318)->bit, data); > + } > } > > void s390_add_from_feat_block(S390FeatBitmap features, S390FeatType type, > diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h > index ef52ffce83..87463f064d 100644 > --- a/target/s390x/cpu_features.h > +++ b/target/s390x/cpu_features.h > @@ -81,6 +81,10 @@ const S390FeatGroupDef *s390_feat_group_def(S390FeatGroup group); > > #define BE_BIT_NR(BIT) (BIT ^ (BITS_PER_LONG - 1)) > > +static inline void clear_be_bit(unsigned int bit_nr, uint8_t *array) > +{ > + array[bit_nr / 8] &= ~(0x80 >> (bit_nr % 8)); > +} > static inline void set_be_bit(unsigned int bit_nr, uint8_t *array) > { > array[bit_nr / 8] |= 0x80 >> (bit_nr % 8); > diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c > index ca484bfda7..461e0b8f4a 100644 > --- a/target/s390x/cpu_models.c > +++ b/target/s390x/cpu_models.c > @@ -29,6 +29,7 @@ > #include "hw/pci/pci.h" > #endif > #include "qapi/qapi-commands-machine-target.h" > +#include "hw/s390x/pv.h" > > #define CPUDEF_INIT(_type, _gen, _ec_ga, _mha_pow, _hmfai, _name, _desc) \ > { \ > @@ -238,6 +239,9 @@ bool s390_has_feat(S390Feat feat) > } > return 0; > } > + if (feat == S390_FEAT_DIAG_318 && s390_is_pv()) { > + return false; > + } > return test_bit(feat, cpu->model->features); > } > > diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c > index f13eff688c..baa070fdf7 100644 > --- a/target/s390x/kvm.c > +++ b/target/s390x/kvm.c > @@ -2498,8 +2498,7 @@ void kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp) > */ > set_bit(S390_FEAT_EXTENDED_LENGTH_SCCB, model->features); > > - /* DIAGNOSE 0x318 is not supported under protected virtualization */ > - if (!s390_is_pv() && kvm_check_extension(kvm_state, KVM_CAP_S390_DIAG318)) { > + if (kvm_check_extension(kvm_state, KVM_CAP_S390_DIAG318)) { > set_bit(S390_FEAT_DIAG_318, model->features); > } > >
On 10/22/20 10:32 AM, David Hildenbrand wrote: > On 22.10.20 10:23, Janosch Frank wrote: >> Diag318 fencing needs to be determined on the current VM PV state and >> not on the state that the VM has when we create the CPU model. >> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> >> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> >> Fixes: fabdada935 ("s390: guest support for diagnose 0x318") >> --- >> >> If you're sure that this is what you want, then I'll send a v2 of the >> patch set. > > So that's going to be the first CPU feature that gets suppressed in PC > mode - which seems to be what we want. > > diag318_needed() will return false, resulting in vmstate_diag318() not > being included in the migration stream (I know, we don't support > migration yet for PV). Well either you have it and need to migrate it or you don't. As it doesn't persist over IPLs, that should not be a problem, no? > > I don't see where diag318 would get reset during a reipl - is it > expected to be persistent when switching in/out of PV, or when reipling > etc..? That's actually another bug we need to address. Diag318 will need to be reset on a diag308 reset instead of when doing the cpu resets... > >> >> --- >> target/s390x/cpu_features.c | 5 +++++ >> target/s390x/cpu_features.h | 4 ++++ >> target/s390x/cpu_models.c | 4 ++++ >> target/s390x/kvm.c | 3 +-- >> 4 files changed, 14 insertions(+), 2 deletions(-) >> >> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c >> index 31ea8df246..42fe0bf4ca 100644 >> --- a/target/s390x/cpu_features.c >> +++ b/target/s390x/cpu_features.c >> @@ -14,6 +14,7 @@ >> #include "qemu/osdep.h" >> #include "qemu/module.h" >> #include "cpu_features.h" >> +#include "hw/s390x/pv.h" >> >> #define DEF_FEAT(_FEAT, _NAME, _TYPE, _BIT, _DESC) \ >> [S390_FEAT_##_FEAT] = { \ >> @@ -105,6 +106,10 @@ 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()) { >> + clear_be_bit(s390_feat_def(S390_FEAT_DIAG_318)->bit, data); >> + } >> } >> >> void s390_add_from_feat_block(S390FeatBitmap features, S390FeatType type, >> diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h >> index ef52ffce83..87463f064d 100644 >> --- a/target/s390x/cpu_features.h >> +++ b/target/s390x/cpu_features.h >> @@ -81,6 +81,10 @@ const S390FeatGroupDef *s390_feat_group_def(S390FeatGroup group); >> >> #define BE_BIT_NR(BIT) (BIT ^ (BITS_PER_LONG - 1)) >> >> +static inline void clear_be_bit(unsigned int bit_nr, uint8_t *array) >> +{ >> + array[bit_nr / 8] &= ~(0x80 >> (bit_nr % 8)); >> +} >> static inline void set_be_bit(unsigned int bit_nr, uint8_t *array) >> { >> array[bit_nr / 8] |= 0x80 >> (bit_nr % 8); >> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c >> index ca484bfda7..461e0b8f4a 100644 >> --- a/target/s390x/cpu_models.c >> +++ b/target/s390x/cpu_models.c >> @@ -29,6 +29,7 @@ >> #include "hw/pci/pci.h" >> #endif >> #include "qapi/qapi-commands-machine-target.h" >> +#include "hw/s390x/pv.h" >> >> #define CPUDEF_INIT(_type, _gen, _ec_ga, _mha_pow, _hmfai, _name, _desc) \ >> { \ >> @@ -238,6 +239,9 @@ bool s390_has_feat(S390Feat feat) >> } >> return 0; >> } >> + if (feat == S390_FEAT_DIAG_318 && s390_is_pv()) { >> + return false; >> + } >> return test_bit(feat, cpu->model->features); >> } >> >> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c >> index f13eff688c..baa070fdf7 100644 >> --- a/target/s390x/kvm.c >> +++ b/target/s390x/kvm.c >> @@ -2498,8 +2498,7 @@ void kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp) >> */ >> set_bit(S390_FEAT_EXTENDED_LENGTH_SCCB, model->features); >> >> - /* DIAGNOSE 0x318 is not supported under protected virtualization */ >> - if (!s390_is_pv() && kvm_check_extension(kvm_state, KVM_CAP_S390_DIAG318)) { >> + if (kvm_check_extension(kvm_state, KVM_CAP_S390_DIAG318)) { >> set_bit(S390_FEAT_DIAG_318, model->features); >> } >> >> > >
On 22.10.20 10:39, Janosch Frank wrote: > On 10/22/20 10:32 AM, David Hildenbrand wrote: >> On 22.10.20 10:23, Janosch Frank wrote: >>> Diag318 fencing needs to be determined on the current VM PV state and >>> not on the state that the VM has when we create the CPU model. >>> >>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >>> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> >>> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> >>> Fixes: fabdada935 ("s390: guest support for diagnose 0x318") >>> --- >>> >>> If you're sure that this is what you want, then I'll send a v2 of the >>> patch set. >> >> So that's going to be the first CPU feature that gets suppressed in PC >> mode - which seems to be what we want. >> >> diag318_needed() will return false, resulting in vmstate_diag318() not >> being included in the migration stream (I know, we don't support >> migration yet for PV). > > Well either you have it and need to migrate it or you don't. > As it doesn't persist over IPLs, that should not be a problem, no? Okay, was confused by no finding a proper reset from our central reset handler. So this feels like the right thing to do.
On Thu, 22 Oct 2020 04:23:12 -0400 Janosch Frank <frankja@linux.ibm.com> wrote: > Diag318 fencing needs to be determined on the current VM PV state and > not on the state that the VM has when we create the CPU model. > > Signed-off-by: Janosch Frank <frankja@linux.ibm.com> > Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> > Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> > Fixes: fabdada935 ("s390: guest support for diagnose 0x318") > --- > > If you're sure that this is what you want, then I'll send a v2 of the > patch set. > > --- > target/s390x/cpu_features.c | 5 +++++ > target/s390x/cpu_features.h | 4 ++++ > target/s390x/cpu_models.c | 4 ++++ > target/s390x/kvm.c | 3 +-- > 4 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c > index 31ea8df246..42fe0bf4ca 100644 > --- a/target/s390x/cpu_features.c > +++ b/target/s390x/cpu_features.c > @@ -14,6 +14,7 @@ > #include "qemu/osdep.h" > #include "qemu/module.h" > #include "cpu_features.h" > +#include "hw/s390x/pv.h" > > #define DEF_FEAT(_FEAT, _NAME, _TYPE, _BIT, _DESC) \ > [S390_FEAT_##_FEAT] = { \ > @@ -105,6 +106,10 @@ 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()) { > + clear_be_bit(s390_feat_def(S390_FEAT_DIAG_318)->bit, data); > + } > } Sorry, I'm a little rusty with cpu models. Does this affect the outcome of the corresponding QMP commands? I would guess it does... Regards, Halil
On 22.10.20 11:54, Halil Pasic wrote: > On Thu, 22 Oct 2020 04:23:12 -0400 > Janosch Frank <frankja@linux.ibm.com> wrote: > >> Diag318 fencing needs to be determined on the current VM PV state and >> not on the state that the VM has when we create the CPU model. >> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> >> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> >> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> >> Fixes: fabdada935 ("s390: guest support for diagnose 0x318") >> --- >> >> If you're sure that this is what you want, then I'll send a v2 of the >> patch set. >> >> --- >> target/s390x/cpu_features.c | 5 +++++ >> target/s390x/cpu_features.h | 4 ++++ >> target/s390x/cpu_models.c | 4 ++++ >> target/s390x/kvm.c | 3 +-- >> 4 files changed, 14 insertions(+), 2 deletions(-) >> >> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c >> index 31ea8df246..42fe0bf4ca 100644 >> --- a/target/s390x/cpu_features.c >> +++ b/target/s390x/cpu_features.c >> @@ -14,6 +14,7 @@ >> #include "qemu/osdep.h" >> #include "qemu/module.h" >> #include "cpu_features.h" >> +#include "hw/s390x/pv.h" >> >> #define DEF_FEAT(_FEAT, _NAME, _TYPE, _BIT, _DESC) \ >> [S390_FEAT_##_FEAT] = { \ >> @@ -105,6 +106,10 @@ 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()) { >> + clear_be_bit(s390_feat_def(S390_FEAT_DIAG_318)->bit, data); >> + } >> } > > Sorry, I'm a little rusty with cpu models. Does this affect the outcome > of the corresponding QMP commands? > > I would guess it does... No, it shouldn't.
diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c index 31ea8df246..42fe0bf4ca 100644 --- a/target/s390x/cpu_features.c +++ b/target/s390x/cpu_features.c @@ -14,6 +14,7 @@ #include "qemu/osdep.h" #include "qemu/module.h" #include "cpu_features.h" +#include "hw/s390x/pv.h" #define DEF_FEAT(_FEAT, _NAME, _TYPE, _BIT, _DESC) \ [S390_FEAT_##_FEAT] = { \ @@ -105,6 +106,10 @@ 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()) { + clear_be_bit(s390_feat_def(S390_FEAT_DIAG_318)->bit, data); + } } void s390_add_from_feat_block(S390FeatBitmap features, S390FeatType type, diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h index ef52ffce83..87463f064d 100644 --- a/target/s390x/cpu_features.h +++ b/target/s390x/cpu_features.h @@ -81,6 +81,10 @@ const S390FeatGroupDef *s390_feat_group_def(S390FeatGroup group); #define BE_BIT_NR(BIT) (BIT ^ (BITS_PER_LONG - 1)) +static inline void clear_be_bit(unsigned int bit_nr, uint8_t *array) +{ + array[bit_nr / 8] &= ~(0x80 >> (bit_nr % 8)); +} static inline void set_be_bit(unsigned int bit_nr, uint8_t *array) { array[bit_nr / 8] |= 0x80 >> (bit_nr % 8); diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c index ca484bfda7..461e0b8f4a 100644 --- a/target/s390x/cpu_models.c +++ b/target/s390x/cpu_models.c @@ -29,6 +29,7 @@ #include "hw/pci/pci.h" #endif #include "qapi/qapi-commands-machine-target.h" +#include "hw/s390x/pv.h" #define CPUDEF_INIT(_type, _gen, _ec_ga, _mha_pow, _hmfai, _name, _desc) \ { \ @@ -238,6 +239,9 @@ bool s390_has_feat(S390Feat feat) } return 0; } + if (feat == S390_FEAT_DIAG_318 && s390_is_pv()) { + return false; + } return test_bit(feat, cpu->model->features); } diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c index f13eff688c..baa070fdf7 100644 --- a/target/s390x/kvm.c +++ b/target/s390x/kvm.c @@ -2498,8 +2498,7 @@ void kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp) */ set_bit(S390_FEAT_EXTENDED_LENGTH_SCCB, model->features); - /* DIAGNOSE 0x318 is not supported under protected virtualization */ - if (!s390_is_pv() && kvm_check_extension(kvm_state, KVM_CAP_S390_DIAG318)) { + if (kvm_check_extension(kvm_state, KVM_CAP_S390_DIAG318)) { set_bit(S390_FEAT_DIAG_318, model->features); }