On Monday 23 October 2006 4:29 pm, Paul Brook wrote: > On Monday 23 October 2006 21:01, Rob Landley wrote: > > On Sunday 22 October 2006 2:27 pm, Paul Brook wrote: > > > I've been considering a machine config file for a while, but haven't come > > > up with a coherent way of representing everything yet. > > > > Do you at least have a list of everything that needs to be represented? (I > > have a list but am fairly certain it's not complete.) > > 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...) 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?) > The really OTT method is to embed a python interpreter or something and do > the machine init that way. I'm not seriously suggesting that though. Thank goodness. :) 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. Fabrice did a good job explaining the CPU part in http://www.usenix.org/events/usenix05/tech/freenix/full_papers/bellard/bellard_html/index.html but that sort of glosses over the support chips, bus, devices, interrupts, dma... Last I checked, each processor was in its own directory (at the top level, not under any kind of processors/ directory), the devices were under "hw", and the motherboards gluing together a bunch of devices were _also_ under "hw". Sorting through that, I read bits of files like "hw/pc.c" where it defines QEMUMachine structures like "pc_machine" where the important thing seems to be pc_init_pci which takes ten arguments and is a wrapper around pc_init1 (which takes eleven). That calls lots of functions to init cpu emulators (_which_ cpu is being initalized seems to be specified elsewhere, possibly by the makefile linking in the right objects), map memory into the virtual MMU, initialize the bios, possibly load a kernel, init the virtual PCI bus (and the PCI to ISA bridge), whatever the heck the two calls to register_ioport_write() do (0x80 and 0xf0... Let's see, http://www.cs.cmu.edu/~ralf/interrupt-list/inter61d.zip file PORT.A. PORT 0080 is "manufacturing diagnostics port", sometimes used for a hex display, and I vaguely remember from way back some linux kernel thread about this (it was being used as a delay, or...?) Bug can't seem to google for it right now. 0xf0 is the math coprocessor.), init the virtual graphics card, init the realtime clock, more I/O port stuff (0x92... PS/2 system control port a, controls the A20 line among other things), setup the ioapic, and the ISA Programmable interrupt controller, the programmable interval timer, pci speaker, do something else with the interrupts, init serial and parallel ports, network cards, ide controllers, keyboard, dma, sound card, floppy controller, cmos, usb, power management, a commented out block of scsi devices, and the pci and acpi bioses. 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... Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel