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

[Markus Armbruster]

David Gibson <dwg at au1.ibm.com> writes:

> On Wed, Feb 11, 2009 at 12:50:28PM -0600, Hollis Blanchard wrote:
>> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
> [snip]
>> > I briefly examined the DT source format and the tree structure it
>> > describes for the purpose of QEMU configuration.  I decided against
>> > using it in my prototype because I found it awfully low-level and
>> > verbose for that purpose (I'm sure it serves the purpose it was designed
>> > for just fine).  Issues include:
>> > 
>> > * Since the DT is designed for booting kernels, not configuring QEMU,
>> >   there's information that has no place in QEMU configuration, and
>> >   required QEMU configuration isn't there.
>> 
>> What's needed is a "binding" in IEEE1275-speak: a document that
>> describes qemu-specific nodes/properties and how they are to be
>> interpreted.
>> 
>> As an example, you could require that block devices contain properties
>> named "qemu,path", "qemu,backend", etc.
>
> Yes, it shouldn't be hard to annotate an IEEE1275 style tree with
> extra information for qemu's use.

I don't feel up to that task, because I'm not really familiar with
IEEE1275.  Could you help out?

>                                    As for the other direction, in some
> cases it may be appropriate for qemu's device tree code to fill in
> missing device tree properties, based on what the device emulation
> code knows about itself.

Agreed.  Configuration should only contain what is actually
configurable.  Anything else that is needed by a consumer of the tree
should be filled in automatically.

>> > * Redundancy between node name and its device_type property.
>
> Note that "device_type" may not mean what you think.  It describes
> what methods the device support within the OF client interface.  New
> device trees that aren't linked to a full OF implementation with
> client interface should generally omit device_type in most places
> (there are a few special cases for compatibility with OSes that expect
> device_type properties in certain places).

I guess the ignorance I mentioned shows ;)

>> > * Property "reg", which encodes address ranges, does so in terms of
>> >   "cells": #address-cells 32-bit words (big endian) for the address,
>> >   followed by #size-cells words for the size, where #address-cells and
>> >   #size-cells are properties of the enclosing bus.  If this sounds
>> >   like gibberish to you, well, that's my point.
>
> #address-cells and #size-cells takes a little getting used to, but
> it's really not that bad.  It's just a way of representing the fact
> that different busses have different sized address encodings.

I didn't mean to say they are a bad idea for FDTs, just that they're on
an awkward level of abstraction for QEMU configuration.  There, I'd
rather express a PCI address as "02:01.0" than as <0x00000220>.
Translating text to binary is the machine's job, not the user's.