Re: [Qemu-devel] Config file support

[Rob Landley]

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