From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gc9Iv-0004Te-NE for qemu-devel@nongnu.org; Mon, 23 Oct 2006 19:34:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gc9It-0004Pt-Cz for qemu-devel@nongnu.org; Mon, 23 Oct 2006 19:33:59 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gc9Is-0004PY-As for qemu-devel@nongnu.org; Mon, 23 Oct 2006 19:33:58 -0400 Received: from [65.74.133.4] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Gc9Ir-0004Hc-Vk for qemu-devel@nongnu.org; Mon, 23 Oct 2006 19:33:58 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Config file support Date: Tue, 24 Oct 2006 00:33:49 +0100 References: <200610232129.53615.paul@codesourcery.com> <200610231822.59310.rob@landley.net> In-Reply-To: <200610231822.59310.rob@landley.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610240033.51392.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: Rob Landley Cc: qemu-devel@nongnu.org > > Not really. I guess a generic key/value pair is sufficient for most > > things (base address, model number, etc). > > The things are what I was asking about. Assuming that QEMU has support for > the appropriate processor type, support for the right bus controller(s), > and support for various devices that can attach to that bus, what other > information is needed to completely specify a machine? (You mention IRQ > lines and DMA channels...) A good first guess is to look at the the *_init functions in the hw/ directory. They should tell you what parameters a device has. > I'm still a little fuzzy about basic questions like "How much information > is in 'processor type'?" (Does that include cache size? Floating point > support? Has mmu flag? Are these separate processors with their own > names, or are they options to a base processor type?) > > I'm generally not worried about parsing data files being hard, I just don't > currently know what's involved in adding a new machine type to QEMU anyway. > don't know what all the data _is_ let alone what to do with it once it's > read in. This is why I suggested a *generic* key/value system. Basically each "device" registers itself with qemu, and provides an initialisation function and a list of properties. qemu doesn't know the meaning of a particular key, just its name and type (number/string/whatever). The machine config file instantiates particular devices (explicitly or implicitly one per section). qemu validates+parses the keys in the config file against the list provided by the device. Then the init function is called. > Last I checked, each processor was in its own directory (at the top level, > not under any kind of processors/ directory), qemu doesn't support different CPUs in the same machine. That's a whole other problem. > the devices were under "hw", > and the motherboards gluing together a bunch of devices were _also_ under > "hw". >... > Currently, this is all hard-wired together into a big blob. Step one of > untangling it would probably be moving the device files and the motherboard > files to separate directories... My intention is that a machine config file would remove the "motherboard" bits altogether. ie. the config file describes everything that pc_init_1 does. The first half of pc.c would remain because that's device emulation. For things like network/serial/disks we need to figure out how to make the machine description adapt to the config the user requested. Proably want to replace the fixed tables eg. bs_table with some mechanism for identifying/requesting disks by name. Likewise if you identify PCI busses and IRQs by name/location this provides a way for the user to wire them up. Most of the code is already fairly well separated. It's just that the glue is hardcoded in C and parameters passed as function arguments rather than being something that is determined at runtime. Take the Integrator/CP board as an example. I'd expect the machine config to look something like: ram {base=0; size=RAM_SIZE, physaddr=0} ram {base=0x80000000; size=RAM_SIZE, physaddr=0} integrator_core{ram_size=RAM_SIZE}; arm_cpu_pic {cpu_index=0, pic_name="CPU0"} integrator_pic {pic_name="PRIMARY", base=0x14000000,parent="CPU0", parent_irq=0, parent_fiq=1} integrator_pic {pic_name="SECONDARY", base=0xca000000, pic="PRIMARY",irq=0, fiq=1} integrator_pit{base=0x13000000, pic="PRIMARY", irq=5} pl011{base=0x16000000, name="serial0", pic="PRIMARY", irq=1} etc. The syntax I just made up, and there are the issues I mentioned above, but hopefully you get the idea. Paul