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(a)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