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@xxxxxxxxxx> 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 > > > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list