On Tue, Dec 03, 2013 at 08:59:52PM +0000, Peter Maydell wrote:
> On 3 December 2013 20:41, Michael S. Tsirkin <m...@redhat.com> wrote:
> > On Tue, Dec 03, 2013 at 06:30:46PM +0000, Peter Maydell wrote:
> >> On 3 December 2013 16:28, Michael S. Tsirkin <m...@redhat.com> wrote:
> >> > const VMStateDescription vmstate_pcie_aer_log = {
> >> > .name = "PCIE_AER_ERROR_LOG",
> >> > .version_id = 1,
> >> > .minimum_version_id = 1,
> >> > .minimum_version_id_old = 1,
> >> > + .post_load = pcie_aer_state_post_load,
> >> > .fields = (VMStateField[]) {
> >> > VMSTATE_UINT16(log_num, PCIEAERLog),
> >> > - VMSTATE_UINT16(log_max, PCIEAERLog),
> >> > - VMSTATE_STRUCT_VARRAY_POINTER_UINT16(log, PCIEAERLog, log_num,
> >> > + VMSTATE_UINT16_EQUAL(log_max, PCIEAERLog),
> >> > + VMSTATE_STRUCT_VARRAY_POINTER_UINT16(log, PCIEAERLog, log_max,
> >> > vmstate_pcie_aer_err, PCIEAERErr),
> >> > VMSTATE_END_OF_LIST()
> >> > }
> >>
> >> Isn't this a migration compability break?
> >
> > How is it a break?
>
> If a QEMU with this patch sends data to a QEMU without it, then the
> receiving end will think it should expect log_num array entries but the
> sending end is going to send log_max of them. Conversely, an old->new
> migration is going to send fewer array entries than the destination
> expects. Or have I misinterpreted how the VARRAY entries work?
>
> thanks
> -- PMM
Ah, got it. You are right, good catch. I think we need VMSTATE_UINT16_LE, this
will
make sure log_num <= log_max without changing
VMSTATE_STRUCT_VARRAY size.
