From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEL1k-0003wj-PA for qemu-devel@nongnu.org; Mon, 04 Aug 2014 12:22:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XEL1e-0006Yi-K5 for qemu-devel@nongnu.org; Mon, 04 Aug 2014 12:22:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53153) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XEL1e-0006YY-Ba for qemu-devel@nongnu.org; Mon, 04 Aug 2014 12:22:18 -0400 Date: Mon, 4 Aug 2014 18:22:27 +0200 From: "Michael S. Tsirkin" Message-ID: <20140804162227.GB22228@redhat.com> References: <1406920333-8297-1-git-send-email-alex@alex.org.uk> <20140804133106.GA17436@redhat.com> <7FF57083-3331-4438-BC09-B8FF14FF0696@alex.org.uk> <20140804142641.GF17674@redhat.com> <580B1DF4-E09D-4F34-9D3F-E74374CF0D93@alex.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <580B1DF4-E09D-4F34-9D3F-E74374CF0D93@alex.org.uk> Subject: Re: [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Ryan Harper , Serge Hallyn , "quintela@redhat.com" , Libvirt , Serge Hallyn , "qemu-devel@nongnu.org" , Alexander Graf , Cole Robinson , Amit Shah , Bruce Rogers , Andreas =?iso-8859-1?Q?F=E4rber?= , "Serge E. Hallyn" On Mon, Aug 04, 2014 at 05:11:11PM +0100, Alex Bligh wrote: > Michael, > > On 4 Aug 2014, at 15:26, Michael S. Tsirkin 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 > > >