On Tue, Apr 23, 2013 at 04:51:36PM +0200, Igor Mammedov wrote:
> On Tue, 23 Apr 2013 16:04:22 +0300
> "Michael S. Tsirkin" <m...@redhat.com> wrote:
>
> > On Tue, Apr 23, 2013 at 02:54:16PM +0200, Igor Mammedov wrote:
> > > On Tue, 23 Apr 2013 13:38:10 +0200
> > > Juan Quintela <quint...@redhat.com> wrote:
> > >
> > > > Igor Mammedov <imamm...@redhat.com> wrote:
> > > >
> > > > >
> > > > > +#define VMSTATE_CPU_STATUS_ARRAY(_field,
> > > > > _state) \
> > > > > +
> > > > > {
> > > > > \
> > > > > + .name =
> > > > > (stringify(_field)), \
> > > > > + .version_id = 0,
> > > > > \
> > > >
> > > > this line should be:
> > > > .version_id = 4,
> > > >
> > > >
> > > > > + .num =
> > > > > PIIX4_PROC_LEN, \
> > > > > + .info =
> > > > > &vmstate_info_uint8, \
> > > > > + .size =
> > > > > sizeof(uint8_t), \
> > > > > + .flags =
> > > > > VMS_ARRAY, \
> > > > > + .offset = vmstate_offset_array(_state, _field,
> > > > > uint8_t, \
> > > > > +
> > > > > PIIX4_PROC_LEN), \
> > > > > + }
> > > > > +
> > > > > /* qemu-kvm 1.2 uses version 3 but advertised as 2
> > > > > * To support incoming qemu-kvm 1.2 migration, change version_id
> > > > > * and minimum_version_id to 2 below (which breaks migration from
> > > >
> > > > > @@ -265,7 +289,7 @@ static int acpi_load_old(QEMUFile *f, void
> > > > > *opaque, int version_id) */
> > > > > static const VMStateDescription vmstate_acpi = {
> > > > > .name = "piix4_pm",
> > > > > - .version_id = 3,
> > > > > + .version_id = 4,
> > > > > .minimum_version_id = 3,
> > > > > .minimum_version_id_old = 1,
> > > > > .load_state_old = acpi_load_old,
> > > > > @@ -281,6 +305,7 @@ static const VMStateDescription vmstate_acpi = {
> > > > > VMSTATE_STRUCT(ar.gpe, PIIX4PMState, 2, vmstate_gpe,
> > > > > ACPIGPE), VMSTATE_STRUCT(pci0_status, PIIX4PMState, 2,
> > > > > vmstate_pci_status, struct pci_status),
> > > > > + VMSTATE_CPU_STATUS_ARRAY(gpe_cpu.sts, PIIX4PMState),
> > > >
> > > > It is more, I think that simply:
> > > >
> > > > VMSTATE_UINT8_ARRAY_V(gpu_cpu.sts, PIIX4PMstate, PIIX4_PROC_LEN, 4);
> > > >
> > > > Should do the trick without the previous blob (it was needed for the old
> > > > version because we have a uint32 data but we send a uint16 one).
> > > >
> > > > Could you check? I don't have an easy way to test that it "receives"
> > > > the right value.
> > > Just checked, it works with VMSTATE_UINT8_ARRAY_V as well,
> > >
> > > but I have a question, why version should be 4, looking at git history
> > > components of vmstate_acpi don't advance their version each time
> > > vmstate_acpi change, they do it only when they themselves change.
> >
> > Generally changing version breaks cross version migration.
> > So please don't do it for an optional
> > feature like CPU hotplug.
> I probably wasn't clear enough, question was about why a new component
> VMSTATE_UINT8_ARRAY_V(gpu_cpu.sts, ...) should be version 4 and not 0?
>
> As for advancing vmstate_acpi version, it was requested:
> http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg04775.html
It says
You need to either bump the version, or add a subsection. The
subsection is not needed until the first hot-(un)plug action.
please add a subsection, don't bump the version :)
>
>
> Anyway why chatting on IRC with Juan, question arises:
> Do we really need to save/restore gpe_cpu.sts field?
>
> Since target has to be started with all CPUs (including hot-plugged), it will
> have the same gpe_cpu.sts bitmap.
>
> > > >
> > > > Later, Juan.
> > > >
> > > > > VMSTATE_END_OF_LIST()
> > > > > }
> > > > > };
> > > > > @@ -585,6 +610,85 @@ static const MemoryRegionOps piix4_pci_ops = {
> > > >
> >
