From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L18mk-0006m2-9N for qemu-devel@nongnu.org; Fri, 14 Nov 2008 19:13:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L18mi-0006lq-SU for qemu-devel@nongnu.org; Fri, 14 Nov 2008 19:13:09 -0500 Received: from [199.232.76.173] (port=34462 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L18mi-0006ln-Kv for qemu-devel@nongnu.org; Fri, 14 Nov 2008 19:13:08 -0500 Received: from mail.codesourcery.com ([65.74.133.4]:50246) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L18mi-0008H1-7n for qemu-devel@nongnu.org; Fri, 14 Nov 2008 19:13:08 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Machine config files Date: Sat, 15 Nov 2008 00:13:03 +0000 References: <200811140332.14093.paul@codesourcery.com> <200811141539.23408.hollisb@us.ibm.com> <491DF47B.9000602@codemonkey.ws> In-Reply-To: <491DF47B.9000602@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811150013.03865.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: devicetree-discuss@ozlabs.org, Hollis Blanchard > > Some translation code would be required for compatibility. For example, > > when the DTS has 128MB of memory, and the user invokes qemu with -m 256, > > now you need to update the device tree in order to pass it into the > > guest. That's pretty easy, but once you start talking about adding PCI > > devices it gets a little more difficult. I seem to recall this > > conversation was had on qemu-devel a little while back. >... > > Of course, *some* code would still be needed *somewhere* to load the > > kernel, initrd, set initial register state to point to those memory > > locations, etc. In the case of KVM on 440, we also need to override the > > DTS with the real host clock frequency. (This probably isn't necessary > > for qemu+TCG.) > > > > But yes, replacing all the pci_nic_init(), isa_mmio_init(), > > cpu_register_physical_memory(), etc could be automated by walking the > > device tree. > > Ok. This is starting to look interesting. Paul, what do you think of DTS? Things like kernel loading are easy, you just add a special device (which linux will ignore) specifying the relevant parameters. IMO it should be possible to use the same device tree for both linux and qemu, but it's ok to require some additional information on top of what linux currently requires. I agree with Hollis that the tricky bits are when you want to augment a board with use supplied options (e.g. RAM size or additional PCI devices). That either requires qemu to modify the supplied device tree, merging multiple trees, or some other magic. I'm ignoring this problem for now. Worst case we remove the existing options, provide a reasonable set of "standard" configs and anyone who wants exotic setups can modify the machine description. I'm mainly interested in emulation, where any host information leaking through to the emulated machine is a bug :-) Paul