From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MHdsb-00029A-S6 for qemu-devel@nongnu.org; Fri, 19 Jun 2009 09:11:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MHdsX-00027I-1R for qemu-devel@nongnu.org; Fri, 19 Jun 2009 09:11:40 -0400 Received: from [199.232.76.173] (port=46307 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHdsW-00027F-RG for qemu-devel@nongnu.org; Fri, 19 Jun 2009 09:11:36 -0400 Received: from mail-qy0-f191.google.com ([209.85.221.191]:49892) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MHdsW-0001qj-Ha for qemu-devel@nongnu.org; Fri, 19 Jun 2009 09:11:36 -0400 Received: by qyk29 with SMTP id 29so2176641qyk.4 for ; Fri, 19 Jun 2009 06:11:36 -0700 (PDT) Message-ID: <4A3B8E56.3040903@codemonkey.ws> Date: Fri, 19 Jun 2009 08:10:46 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] sending pci information over the wire References: <20090618193946.GH3517@poweredge.glommer> <4A3A9D89.5000305@codemonkey.ws> <20090618201227.GI3517@poweredge.glommer> <4A3AA5D8.8050303@codemonkey.ws> <4A3B527C.2010203@redhat.com> In-Reply-To: <4A3B527C.2010203@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: Gerd Hoffmann Cc: Glauber Costa , qemu-devel@nongnu.org, armbru@redhat.com Gerd Hoffmann wrote: > On 06/18/09 22:38, Anthony Liguori wrote: >> Glauber Costa wrote: >>> Sure. >>> >>> Question is, whether or not there is any value in doing this now. > > Prototyping, playing with it, figure any roadblocks: yes. > Merging: no. > > I think we should go for the "big" solution, i.e. machine-config for > *everything*, not just PCI. The move from the current model to the > machine-config based one will be difficuilt enougth, we should not > make it even harder to support by merging a half-done interim solution. > >> We're really close to a machine config for pc though, I'm not sure that >> that's not a quicker solution. > > Well, we are not *that* close. > > Paul Brooks fdt works fine for some simple embedded boards. To make > it fly with pc a noticable amount of work is needed (I'm working on > that ;). Partly that is a simple conversion of drivers to qdev. > Partly that involves reorganization and cleanup of drivers and > subsystems and the dependencies they have. Which certainly is a good > thing because it cleans up the code. But it needs to be done before > machine-config can work for pc. I've been considering queue all patches on the list to keep track of which ones don't get applied. The problem is, something like your qdev series really needs to be applied quickly because it conflicts with quite a lot of other patches. My plan for your qdev series is to give a little more time for feedback, then ask you to rebase/resubmit so they can be applied. Give it a couple more days to give people a chance to review. > Likewise devtree: Paul posted the patches, got a number of reviews > comments. No discussion of the concerns happened though. There is > also no activity in Pauls git tree. I think we're all just waiting for Paul to commit something. > There are some quite fundamental design issues which need to be > decided: > > (1) How will we handle fdt and hotplug? We can keep the qdev tree > and the fdt in sync all the time. Or we generate a fresh fdt > from the qdev tree when needed (i.e. for savevm, migration and > maybe the ppc kernel). I'd lean toward the later. > (2) Depending on (1): How will we handle attributes? Read/write > directly from/to the fdt? Keep them in qdev data structures? I think qdev is the master tree and fdt just becomes a conversion format. > I really like to see some progress here, otherwise 2017 wouldn't be > just a running gag. I agree. Not every patch is reasonable to commit in 24 hours though. Some require giving people appropriate time to review. I think something we could do better is avoiding losing track of patches though. I'm working on that. Regards, Anthony Liguori > cheers, > Gerd