| Message ID | 5bd135ce-ed8e-3326-04b7-3bff51ecc78a@de.ibm.com |
|---|---|
| State | New |
| Headers | show |
On Thu, 13 Jul 2017 15:58:30 +0200 Christian Borntraeger <borntraeger@de.ibm.com> wrote: > On 07/13/2017 03:10 PM, Cornelia Huck wrote: > > On Thu, 13 Jul 2017 15:02:08 +0200 > > Christian Borntraeger <borntraeger@de.ibm.com> wrote: > > > >> On 07/13/2017 02:27 PM, Cornelia Huck wrote: > >>> On Thu, 13 Jul 2017 12:40:29 +0200 > >>> Christian Borntraeger <borntraeger@de.ibm.com> wrote: > >>> > >>>> From: Yi Min Zhao <zyimin@linux.vnet.ibm.com> > >>>> > >>>> During migration we should transfer ais states to the target guest. > >>>> This patch introduces a subsection to kvm_s390_flic_vmstate and new > >>>> vmsd for qemu_flic. The ais states need to be migrated only when > >>>> ais is supported. > >>>> > >>>> Signed-off-by: Yi Min Zhao <zyimin@linux.vnet.ibm.com> > >>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> > >>>> --- > >>>> hw/intc/s390_flic.c | 20 ++++++++++++ > >>>> hw/intc/s390_flic_kvm.c | 75 ++++++++++++++++++++++++++++++++++++++++++++ > >>>> include/hw/s390x/s390_flic.h | 1 + > >>>> 3 files changed, 96 insertions(+) > > > >>>> +static int kvm_flic_ais_post_load(void *opaque, int version_id) > >>>> +{ > >>>> + KVMS390FLICStateMigTmp *tmp = opaque; > >>>> + KVMS390FLICState *flic = tmp->parent; > >>>> + struct kvm_s390_ais_all ais = { > >>>> + .simm = tmp->simm, > >>>> + .nimm = tmp->nimm, > >>>> + }; > >>>> + struct kvm_device_attr attr = { > >>>> + .group = KVM_DEV_FLIC_AISM_ALL, > >>>> + .addr = (uint64_t)&ais, > >>>> + }; > >>>> + > >>>> + if (!ais_needed(flic)) { > >>>> + return -ENOSYS; > >>>> + } > >>> > >>> I do not understand this... does that mean that > >>> - we should never get here or > >>> - we should not try to change the fields or > >>> - I need coffee? > >> > >> My understanding is that this should not happen with a normal setup, > >> but it can happen if the user does something "wrong". For example > >> use qemu without libvirt and with -cpu host (which is not migration safe) > >> and do a migration from a host that has AIS to a host that has no AIS. > >> In that case the target system will reject the migration (late, but hopefully > >> not too late). > > > > A comment would be helpful here. > > Something like > > diff --git a/hw/intc/s390_flic_kvm.c b/hw/intc/s390_flic_kvm.c > index 4cf73ee..9b8dbd1 100644 > --- a/hw/intc/s390_flic_kvm.c > +++ b/hw/intc/s390_flic_kvm.c > @@ -452,6 +452,12 @@ static int kvm_flic_ais_post_load(void *opaque, int version_id) > .addr = (uint64_t)&ais, > }; > > + /* This can happen when the user mis-configures its guests in an > + * incompatible fashion or without a CPU model. For example using > + * qemu with -cpu host (which is not migration safe) and do a > + * migration from a host that has AIS to a host that has no AIS. > + * In that case the target system will reject the migration here. > + */ > if (!ais_needed(flic)) { > return -ENOSYS; > } With that added: Reviewed-by: Cornelia Huck <cohuck@redhat.com>
diff --git a/hw/intc/s390_flic_kvm.c b/hw/intc/s390_flic_kvm.c index 4cf73ee..9b8dbd1 100644 --- a/hw/intc/s390_flic_kvm.c +++ b/hw/intc/s390_flic_kvm.c @@ -452,6 +452,12 @@ static int kvm_flic_ais_post_load(void *opaque, int version_id) .addr = (uint64_t)&ais, }; + /* This can happen when the user mis-configures its guests in an + * incompatible fashion or without a CPU model. For example using + * qemu with -cpu host (which is not migration safe) and do a + * migration from a host that has AIS to a host that has no AIS. + * In that case the target system will reject the migration here. + */ if (!ais_needed(flic)) { return -ENOSYS; }