From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LXg0Z-0005ig-G3 for qemu-devel@nongnu.org; Thu, 12 Feb 2009 13:09:55 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LXg0Y-0005iS-LL for qemu-devel@nongnu.org; Thu, 12 Feb 2009 13:09:54 -0500 Received: from [199.232.76.173] (port=36460 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LXg0Y-0005iP-GC for qemu-devel@nongnu.org; Thu, 12 Feb 2009 13:09:54 -0500 Received: from mx2.redhat.com ([66.187.237.31]:54370) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LXg0Y-0006pY-0w for qemu-devel@nongnu.org; Thu, 12 Feb 2009 13:09:54 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n1CI9qbp011917 for ; Thu, 12 Feb 2009 13:09:52 -0500 Date: Thu, 12 Feb 2009 16:09:25 -0200 From: Marcelo Tosatti Subject: Re: [Qemu-devel] [RFC] Machine description as data Message-ID: <20090212180925.GA18971@amt.cnet> References: <87iqnh6kyv.fsf@pike.pond.sub.org> <1234378228.28751.79.camel@slate.austin.ibm.com> <87k57w0x4r.fsf@pike.pond.sub.org> <200902121607.39588.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902121607.39588.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: Markus Armbruster On Thu, Feb 12, 2009 at 04:07:39PM +0000, Paul Brook wrote: > > * Point me to the FDT code I'm supposed to integrate. I'm looking for > > basic decorated tree stuff: create trees, traverse them, get and put > > properties, add and delete nodes, read and write them as plain, > > human-readable text. > > I've been threatening to merge my FDT code for a while, but haven't got round > to it. I've attached A drop of my current code, along with a bunch of > example devices (I haven't yet converted any of the current machines). > The basic strategy is the devices should only have deal with this interface, > and not with teh config structures or the rest of qemu directly. Register > windows and interrupts are converted, but things like DMA accesses still use > the old interfaces. > > Most of the devices (e.g. the serial port) support both new and old init > methods. A few (e.g. nand controller) are pure devtree based devices. > > Paul Ok, so a few questions: - Should host side parameters live inside particular device nodes, as properties? (or to what extent). For example (from early brainstorm Markus wrote). / { model = "pc"; // -M cpus { model = "coreduo"; // -cpu smp = 2; // -smp } // PCI host bridge @domain:bus pci@0000:00 { // devices on this bus @device.function device@1 { // PIIX3 model = "PIIX3"; ata { device@0 { device_type = "disk"; drive { format = "raw"; file = "/var/lib/libvirt/images/hd.img" cache = "none"; }; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ There is a mapping between QEMUDevice <-> disk (1:1). See dt_piix3_config/dt_drive_config on Markus's code. Oh: if (dc->has_chardev) { int n; propstr = fdt_getprop_string(dt, node, "chardev"); if (propstr) { i = sscanf(propstr, "serial%d", &n); if (i == 1 && n >= 0 && n < MAX_SERIAL_PORTS) d->chardev = serial_hds[n]; } } Can you show a working example tree? OTOH vlans and nics have a QEMUDevice -> vlan mapping (vlans are not part of the emulated hardware device tree). Where they belong? For starters, for i386, one can append command line parameters to a static tree containing basic PIIX hw, then have the board code (pc.c) use that. But both prototypes look similar in essence. I can't find QEMUDevice linked in a tree in your code though. It should be possible to, for example, hot add a PCI device, link it in, and dump the updated tree with a monitor command.