From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MNrzi-00038w-Lx for qemu-devel@nongnu.org; Mon, 06 Jul 2009 13:28:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MNrzd-00037c-IG for qemu-devel@nongnu.org; Mon, 06 Jul 2009 13:28:45 -0400 Received: from [199.232.76.173] (port=50918 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNrzd-00037Z-AV for qemu-devel@nongnu.org; Mon, 06 Jul 2009 13:28:41 -0400 Received: from mail-px0-f201.google.com ([209.85.216.201]:52398) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MNrzc-00084w-W1 for qemu-devel@nongnu.org; Mon, 06 Jul 2009 13:28:41 -0400 Received: by pxi39 with SMTP id 39so1067573pxi.4 for ; Mon, 06 Jul 2009 10:28:40 -0700 (PDT) Message-ID: <4A523444.30002@codemonkey.ws> Date: Mon, 06 Jul 2009 12:28:36 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/4] Machine config files References: <20090610173803.4674.82538.stgit@wren.home> <878wjx374h.fsf@pike.pond.sub.org> <4A3269C3.3050307@redhat.com> <4A327E2C.1060207@siemens.com> <20090706124928.GB11998@redhat.com> <4A51FF7B.4000602@redhat.com> <20090706135616.GA12141@redhat.com> <20090706140129.GB12141@redhat.com> <4A520CC6.7060802@redhat.com> <4A52226C.8060606@redhat.com> <4A5225D6.8030102@redhat.com> <4A52284C.9080604@redhat.com> In-Reply-To: <4A52284C.9080604@redhat.com> 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: Avi Kivity Cc: Jan Kiszka , "Michael S. Tsirkin" , Gerd Hoffmann , Markus Armbruster , qemu-devel@nongnu.org Avi Kivity wrote: > >> That alone will *not* provide the position in the device tree >> though. And I suspect making the transition without breaking >> backward compatibility could be quite tricky too. So I'm not sure >> how useful that actually is, although it surely would be much cleaner >> from a design point of view. > > I think we need to break the format. It's semi-broken anyway wrt > hotplug and the use of ram addresses. It may be possible to add > transition code but I don't think it's worth it. The format is fine. ram v3 uses ram_addr_t because it's was the only sane thing to do at the time. v4 could easily use target_phys_t. Most importantly, machine config should not be sent until non-live migration kicks in. At this point, the device tree is stable because the guest isn't running. The device tree should be the first section saved for non-live migration. This means you need to avoid initializing the device model until after you get to the second step in migration. You really just need to register any live migration handlers outside of the device model creation which pretty much already happens today. Regards, Anthony Liguori