Re: [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Aug 04, 2014 at 05:11:11PM +0100, Alex Bligh wrote:
> Michael,
> 
> On 4 Aug 2014, at 15:26, Michael S. Tsirkin <mst@redhat.com> wrote:
> 
> >> 
> >> Unless I'm missing what you are saying?
> > 
> > I think you are: check how vmstate_test_use_acpi_pci_hotplug
> > and vmstate_test_no_use_acpi_pci_hotplug are used
> > in vmstate_acpi.
> 
> I /think/ you are talking about using the VMSTATE_FOO_TEST
> macros.

These use field_exists internally.

> These are capable of modifying fields within the
> VMStateDescription of the relevant object.
> 
> However, the PIIX4 change modifies the minimum_version_id
> (outside fields); I don't quite see how that would work.
> Can you help here?

If you want to support lower version IDs,
you can just decrease minimum_version_id.

field_exists gets the version ID so you can
parse different fields depending on the
version.


> The i8254 change modifies a field which is marked with
> a minimum version to be a field with no versioning; I
> guess the route there would be a test function that
> (somehow) accesses the version of the inbound migration
> inside it,

Yes, field_exists gets the version value so no problem here.

> does the comparison manually, and returns
> 1 if EITHER the inbound version >=3 or the compatibility
> thing is set.
> 
> Is that what you meant?

I think so, yes.

> I'm rather new to this so
> you may have to lead me a little - apologies.
> 
> I was trying to produce code which would be 'obviously
> correct' in the sense of not breaking the existing pc-1.0
> migrations; if playing around with the existing vmstate
> fields is permissible then clearly I have a few more
> degrees of freedom.

Yes I think is should be simple but not to the
exclusion of maintainability.

> I did try modifying the objects live after the command
> line has been parsed; this doesn't work because the
> QOM inheritance memcpy's the structs for classes derived
> from i8254 etc.

Right, just add a new flag for this thing.

> -- 
> Alex Bligh
> 
> 
>