From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L14hp-0005RZ-8Y for qemu-devel@nongnu.org; Fri, 14 Nov 2008 14:51:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L14hn-0005RL-OV for qemu-devel@nongnu.org; Fri, 14 Nov 2008 14:51:48 -0500 Received: from [199.232.76.173] (port=50091 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L14hn-0005RI-EV for qemu-devel@nongnu.org; Fri, 14 Nov 2008 14:51:47 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]:38010) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L14hm-0007JG-TX for qemu-devel@nongnu.org; Fri, 14 Nov 2008 14:51:47 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mAEJpFdZ025075 for ; Fri, 14 Nov 2008 12:51:15 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAEJpgIm096880 for ; Fri, 14 Nov 2008 12:51:42 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAEJpfff015900 for ; Fri, 14 Nov 2008 12:51:42 -0700 From: Hollis Blanchard Subject: Re: [Qemu-devel] Machine config files Date: Fri, 14 Nov 2008 13:51:40 -0600 References: <200811140332.14093.paul@codesourcery.com> <491DD188.6000603@codemonkey.ws> In-Reply-To: <491DD188.6000603@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811141351.40613.hollisb@us.ibm.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: devicetree-discuss@ozlabs.org, qemu-devel@nongnu.org On Friday 14 November 2008 13:29:12 Anthony Liguori wrote: > Blue Swirl wrote: > > On 11/14/08, Paul Brook wrote: > > > >> It's come up in other contexts recently, so I think it's worth mentioning that > >> I am currently working on adding a machine config file support to qemu. > >> > >> I am focusing on the board setup side of things, rather than the user-level > >> config side. My goal is to come up with a system that will allow e.g. the > >> entirety of realview.c and gumstix.c to be eliminated. Currently this is > >> based this round Flattened Device Trees (as used by ppc-linux). > >> > >> I have looked at the bits that Fabrice did a while ago. While that contains > >> some good ideas (which I will probably steal!) it is approaching the problem > >> from a somewhat different direction. FTDs are a much better fit for some of > >> my requirements (e.g. being able to pass the config through to the guest OS). > >> > > > > libfdt looks like an excellent choice for both Sparc32 and Sparc64, I > > think the whole OF tree can be represented with it. > > > > The config could be passed using the firmware configuration device. > > > > I was looking through libfdt too. I think it could also be used for > x86. Hollis, I was looking through the Bamboo code, any reason you > don't describe the bus/device layouts in the DTS and then use that to > determine what bus/nic to add? We do; PLB, OPB, and EBC are all on-chip busses found on IBM PowerPC SoCs. For example, you can see devices representing the UARTs and PCI controller in our bamboo.dts file. Qemu only modifies the device tree at runtime with information not known until then (memory size, clock frequency, etc). You may mean why don't we enumerate *PCI* devices in the device tree. Since libfdt is used for embedded systems, this is a tradeoff that allows us to keep the device tree smaller -- why put lots of PCI nodes in the device tree, when the OS can easily discover them itself? That said, PCI devices are indeed found in the device tree in IBM Power servers; Linux just doesn't require them. The Bamboo board in particular doesn't have any on-board PCI devices, but it does have several PCI slots. Therefore, a Bamboo device tree in qemu wouldn't contain any PCI devices anyways, but if the user says "I have an e1000", qemu could add a device node to represent the e1000 (though again, this is not a Linux requirement). (Actually, I don't think the above addresses your specific question, but I went to the trouble of typing it so I figured I'd leave it in this mail for additional background. :) Getting back to your original question, we could include an e1000 PCI device node in the DTS file, and have qemu walk the tree, find the node, and initialize the e1000 emulation driver. We didn't do this mostly to maintain compatibility with existing qemu practice, where users are required to specify all configuration on the command line. -- Hollis Blanchard IBM Linux Technology Center