From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MQkFq-0001tb-IT for qemu-devel@nongnu.org; Tue, 14 Jul 2009 11:49:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MQkFl-0001tO-7k for qemu-devel@nongnu.org; Tue, 14 Jul 2009 11:49:17 -0400 Received: from [199.232.76.173] (port=38383 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MQkFl-0001tL-27 for qemu-devel@nongnu.org; Tue, 14 Jul 2009 11:49:13 -0400 Received: from rv-out-0708.google.com ([209.85.198.245]:21601) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MQkFk-00038K-LU for qemu-devel@nongnu.org; Tue, 14 Jul 2009 11:49:12 -0400 Received: by rv-out-0708.google.com with SMTP id b17so749969rvf.22 for ; Tue, 14 Jul 2009 08:49:11 -0700 (PDT) Message-ID: <4A5CA8F4.8050908@codemonkey.ws> Date: Tue, 14 Jul 2009 10:49:08 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4A5C3FBB.10306@siemens.com> <4A5C9EDF.3060705@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] monitor: Add port write command List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Jan Kiszka , qemu-devel Juan Quintela wrote: > We were thinking about that functionality some time ago. We were > looking at an apic bug during migration, and it was not trivial to dump > apic state before and after migration. > > I took a look at it, and basically decided that I would have to > replicate the savevm method. Your apprearch mean that doing the command > is trivial, and we have "meaningful" labels for it. > > Will take a look at using that in some driver. > Great. I think an incremental conversion is the right approach. If we tie this into qdev correctly, then we could also do some nice things with migration. We could dump out a file that describes any given migration protocol version. We could then use this to automatically check whether we broke the migration format between versions but just doing a diff. I think there's also an opportunity to adjust the migration protocol. One change I had to make to the savevm format was removing all of the size parameters. This is because the nature of QEMUFile makes it such that you don't know what the size was until you actually wrote data. The old savevm format used to rely on seeking to update the size parameter. If we know the size of the section (based on the description), we can reintroduce this to the protocol. What's more, we can probably get rid of QEMUFile all together and introduce a more useful abstraction that doesn't have such complex buffering. This refactoring is definitely high on my 0.12 wish list :-) Regards, Anthony Liguori