From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCYgE-0000GM-98 for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:10:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCYg9-0000Ew-Pp for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:10:10 -0500 Received: from [199.232.76.173] (port=52613 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCYg9-0000Eh-Gw for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:10:05 -0500 Received: from mail-qy0-f194.google.com ([209.85.221.194]:34981) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCYg4-00055b-MB for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:10:01 -0500 Received: by qyk32 with SMTP id 32so2513313qyk.4 for ; Mon, 23 Nov 2009 05:09:53 -0800 (PST) Message-ID: <4B0A899F.2090805@codemonkey.ws> Date: Mon, 23 Nov 2009 07:09:51 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts References: <4B0952C9.9010803@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: dlaor@redhat.com, qemu-devel Juan Quintela wrote: > Dor Laor wrote: > > I will go further, and think that this kind of issues should be put into > the machine type. > I agree. > If you start qemu with -M pc-0.10, it should save the state in a 0.10 > compatible way (that don't happens at the moment, but it should work > that way). > Yes, that's a very good point. >> The solution here is simpler - Every guest visible change should >> translate into cmdline option. This is part of the machine type and >> in addition should be configurable. >> It's an issue we all should keep in the back of our heads and popup >> when a new capability/change are introduced. >> > > I think this creates again a exponential posibilities, when we are only > interested in some small part of the combinations. > > Upstream: It only cares about what was is 0.10, 0.11 and 0.12, three > combinations, not all possible combinations of all devices. > > Downstream: (we for instance) care about RHEL5.4 RHEL5.5 or similar, not > all other possible combinations. > > Notice that this is important, we change devices constantly, but we need > new machine types ... once each X months, i.e. they are much less. > Yes, I think this is an important point to keep things under control. Supporting all possible combinations of different git versions is going to be unrealistically difficult. However, making sure that we can reproduce the major versions would work well. A test suite that ran in the guest and tried to fingerprint the machine would be pretty helpful. Dump the full config for each PCI device, where they sit in the device model, etc. Dump ACPI tables. For a subset of devices we support, query as much info as possible. Dump it all to a config file. We could run it against 0.11, then when 0.12 rolls around, run it again in a guest with -M pc-0.11. A simple diff of the two config files would tell us whether we broke guest compatibility. >> Which protocol should we use? You're smarter than me, please suggest >> one. >> wrt the above guest abi issue, we should write a qemu spec with clear >> definitions for devices, drivers, versions, etc. >> >> Looking forward interesting fruitful discussion, >> > > My idea here is that we need to have further use of machine > descriptions, once that is done, we need something like a new property > for qdev (version?). Once there, each device could do: > - if version != last_version -> die (what it happens now) > - do someting sensible, not use the "new" features not existing on that > version > - edit the savevm format in an easy way. > But this would only kick in when using pc-0.11 or something, right? Regards, Anthony Liguori