From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mdfoh-0006by-Ud for qemu-devel@nongnu.org; Wed, 19 Aug 2009 03:42:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mdfoc-0006be-Ca for qemu-devel@nongnu.org; Wed, 19 Aug 2009 03:42:42 -0400 Received: from [199.232.76.173] (port=42563 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mdfoc-0006bX-6n for qemu-devel@nongnu.org; Wed, 19 Aug 2009 03:42:38 -0400 Received: from mx20.gnu.org ([199.232.41.8]:34569) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mdfob-0008Fr-FC for qemu-devel@nongnu.org; Wed, 19 Aug 2009 03:42:37 -0400 Received: from [66.187.237.31] (helo=mx2.redhat.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mdfoa-0005R2-N7 for qemu-devel@nongnu.org; Wed, 19 Aug 2009 03:42:37 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7J7gZvj031553 for ; Wed, 19 Aug 2009 03:42:35 -0400 Message-ID: <4A8BACBA.9020107@redhat.com> Date: Wed, 19 Aug 2009 09:41:46 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH RFC 0/5] New VMState table based load/save infrastructure References: 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: qemu-devel@nongnu.org > What do I want to discuss: > a- do we want to be able to load state form old versions? > I am not sure that we are going to get this right for complex devices, > and I don't completely see how we can have any kind of testing here. > There was already a discussion about this on the list. Yes, we want. And I think the right approach to do that is to simply use the old, existing code and switch based on version_id. To stick with the apic example: When loadvm finds a v2 (or older) apic section, go call apic_load. When loadvm finds a v3 (or newer) apic section, call the new generic load code with the apic vmstatefield list. > b- Is this the right approach? What more do we want/need? > For instance, implementing struct save support, and calling > other "sub-descriptions" is not difficult, we just have to decide > if we want it. Yes, we want. PCI devices call a generic function to save pci state. We want a common pci vmstatefield list too and have some way to refer to them from the device tables. > c- In the current approach, we have loops to send arrays, I think that one > got already done better on new approarch. But we don't have support > for ifs (see hw/ide.c > if (s->identify_set) { > qemu_get_buffer(f, (uint8_t *)s->identify_data, 512); > } > Do we want support for things like that? No. We want fixed-sized sections, bonus points for a 'size' field in the header. Just save everything unconditionally. The current save/load functions do way too much stuff conditionally. Saving a few bytes simply isn't worth the complexity of getting that right. > d- how aggresive should the new design be? i.e. be able to be compatible with > old design is good, or can we start with a clean sheet and just remove the > gotchas of the previous design? Handle compatibility by keeping the old load functions and start over with a clean sheet. cheers, Gerd