> > 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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
