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
