Re: [Qemu-devel] Config file support

[Paul Brook <paul@codesourcery.com>]

> > 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