On Thu, 8 Feb 2018 11:24:48 +0100
Christian Borntraeger <borntrae...@de.ibm.com> wrote:
> On 02/08/2018 11:16 AM, Cornelia Huck wrote:
> > On Thu, 8 Feb 2018 10:48:08 +0100
> > Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> wrote:
> >> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> >> index 3807dcb..3e6360e 100644
> >> --- a/hw/s390x/s390-virtio-ccw.c
> >> +++ b/hw/s390x/s390-virtio-ccw.c
> >> @@ -373,7 +373,7 @@ static void s390_machine_reset(void)
> >> /* all cpus are stopped - configure and start the ipl cpu only */
> >> s390_ipl_prepare_cpu(ipl_cpu);
> >> - s390_cpu_set_state(CPU_STATE_OPERATING, ipl_cpu);
> >> + s390_cpu_set_state(CPU_INFOS390_STATE_OPERATING, ipl_cpu);
> > Exposing the state as a QAPI enum has the unfortunate side effect of
> > that new name. It feels slightly awkward to me, as it is a state for
> > real decisions and not just for info statements...
> I asked Viktor to use the qapi enum instead of having two sets of defines that
> we need to keep in sync. (in fact 3, as the kernel kvm mpstate definition is
Agreed, using the QAPI enum makes sense.
> But yes, the INFO in that name is somewhat strange. No good idea though.
Can we call the enum CpuS390State instead of CpuInfoS390State (while
keeping the CpuInfoS390 name)? Or does that violate any QAPI rules?