Re: [Qemu-devel] [RFC] Machine description as data

[Marcelo Tosatti <mtosatti@redhat.com>]

On Thu, Feb 12, 2009 at 04:07:39PM +0000, Paul Brook wrote:
> > * Point me to the FDT code I'm supposed to integrate.  I'm looking for
> >   basic decorated tree stuff: create trees, traverse them, get and put
> >   properties, add and delete nodes, read and write them as plain,
> >   human-readable text.
> 
> I've been threatening to merge my FDT code for a while, but haven't got round 
> to it.  I've attached A drop of my current code, along with a bunch of 
> example devices (I haven't yet converted any of the current machines). 
> The basic strategy is the devices should only have deal with this interface, 
> and not with teh config structures or the rest of qemu directly. Register 
> windows and interrupts are converted, but things like DMA accesses still use 
> the old interfaces.
> 
> Most of the devices (e.g. the serial port) support both new and old init 
> methods. A few (e.g. nand controller) are pure devtree based devices.
> 
> Paul

Ok, so a few questions:

- Should host side parameters live inside particular device nodes, as
  properties? (or to what extent). For example (from early brainstorm
  Markus wrote).

/ {
        model = "pc";                   // -M
        cpus {
                model = "coreduo";      // -cpu
                smp = 2;                // -smp
        }
    // PCI host bridge @domain:bus
        pci@0000:00 {
                // devices on this bus @device.function
                device@1 {              // PIIX3
                        model = "PIIX3";
                        ata {
                                device@0 {
                                        device_type = "disk";
                                        drive {
                                                format = "raw";
                                                file = "/var/lib/libvirt/images/hd.img"
                                                cache = "none";
                                        };
                                                
                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

There is a mapping between QEMUDevice <-> disk (1:1). See
dt_piix3_config/dt_drive_config on Markus's code. Oh:

    if (dc->has_chardev) {
        int n;
        propstr = fdt_getprop_string(dt, node, "chardev");
        if (propstr) {
            i = sscanf(propstr, "serial%d", &n);
            if (i == 1 && n >= 0 && n < MAX_SERIAL_PORTS)
                d->chardev = serial_hds[n];
        }
    }

Can you show a working example tree?

OTOH vlans and nics have a QEMUDevice -> vlan mapping (vlans are not
part of the emulated hardware device tree). Where they belong?

For starters, for i386, one can append command line parameters to a
static tree containing basic PIIX hw, then have the board code (pc.c)
use that.

But both prototypes look similar in essence. I can't find QEMUDevice
linked in a tree in your code though. It should be possible to, for
example, hot add a PCI device, link it in, and dump the updated tree
with a monitor command.