From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MNr29-0004Ux-SP for qemu-devel@nongnu.org; Mon, 06 Jul 2009 12:27:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MNr24-0004TO-Fd for qemu-devel@nongnu.org; Mon, 06 Jul 2009 12:27:12 -0400 Received: from [199.232.76.173] (port=41971 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MNr24-0004TL-Aq for qemu-devel@nongnu.org; Mon, 06 Jul 2009 12:27:08 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52813) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MNr23-00081i-T4 for qemu-devel@nongnu.org; Mon, 06 Jul 2009 12:27:08 -0400 Message-ID: <4A5225D6.8030102@redhat.com> Date: Mon, 06 Jul 2009 18:27:02 +0200 From: Gerd Hoffmann 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> In-Reply-To: <4A52226C.8060606@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: qemu-devel@nongnu.org, Jan Kiszka , Markus Armbruster , "Michael S. Tsirkin" On 07/06/09 18:12, Avi Kivity wrote: > On 07/06/2009 05:40 PM, Gerd Hoffmann wrote: >> It might make sense to integrate savevm callbacks into qdev, then >> you'd have actually a chance to figure which driver belongs to your >> piece of savevm state. > > That's my preference. The very first pass iterates the device tree and > serializes it. Sure, needs to happen. I meant something else though: Instead of having the drivers call register_savevm() in there init functions add section name and savevm/loadvm function pointers to qdevs DeviceInfo. That will add the missing link section name -> driver. 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 suspect it isn't enougth to make it work though, you still need to >> know the position of the device in the device tree. To answer >> questions like "is your pci device behind a bridge and if so which one?". > > Isn't that info provided by qdev? Yep, it is. Serialize qdev tree (into fdt or whatever else), send it over wire first, recreate qdev tree on the other side (including save/load callback registration), then parse everything else. That is how I wanna have it work some day ... cheers, Gerd