SV: [Qemu-devel] Machine description, an alternativ using XML

[Torbjörn Andersson]

Thanks for your replies. I do not really aim to force my solution into QEMU,
but I try visualize the good parts. It would be a bonus if my code end up
contributed.

I recognize that my XML usage is quite poor. I will tight it up according to
Jamie's suggestion. I solved my problem at the time and it have been good
enough since then. We have now been using it with lots of targets, >20. We
have been able to identify the common parts of our machines and decreased
our maintenance code and duplication. 

Paul B wrote:
> It looks like you're just using XML to encapsulate simple <key,value>
> pairs,
> which IMHO is completely the wrong way to use XML.

I don't see the fundamental difference compared to FDT. Does it mean that
FDT is wrong too? I guess you can explain a bit more.

mpic: address@hidden {
  interrupt-controller;
  #address-cells = <0>;
  #interrupt-cells = <2>;
  reg = <0x40000 0x40000>;
  compatible = "chrp,open-pic";
  device_type = "open-pic";
};

Note: if FDT fulfills our requirements, I expect that we will move to FDT
too.

All our QEMU knows about is classes, attributes and interfaces. Clusters and
Machines are simply specialized classes. Defining machines/clusters in our
solution is like picking building blocks and sticking them together in XML.
A building block could be a PIC or an entire cluster.

There is no "naming-convention" in our XML solution what so ever. The reason
for why we have object reference described as strings like ":pic" are two.
(pic is simply a suitable name for a pl190)

First we have a layered design, where a cluster/machine describes one layer.
A cluster in our design could as an example be the OMAP SOC. The OMAP SOC is
alone not a machine. It needs to be complemented with RAM and other stuff
and that defines the machine and hooks it together with known parts in the
OMAP cluster. The OMAP itself could also be defined with other clusters.
Therefore the ':' in the object reference tells QEMU where to look.  

The second reason is that we do not want to use fully qualified names
because we might want to run two or more machines within the same QEMU
instance. We prefer to have all machines in one QEMU instance because it is
easier to control and deterministic. (I can submit patches for this too,
including CPU threading support)

In the end we got object names like this
<instance name of machine>
<instance name of machine>_<OMAP name defined in machine>
<instance name of machine>_<OMAP name defined in machine >_<name within the
omap cluster>

I recommend having named objects because it makes life easier when debugging
the state of the machine. Imagine having several objects of the same class
and only be able to separate them with the address to the state-struct. We
also have a object browser, where we can browse the machine and all its
components with current values on attributes, quite powerful and useful for
both users and QEMU developers.

I want to mention on more thing about our clusters and machines. In our XML
solution a cluster can be coupled with a specific "builder" class. The
standard builder, used when none is specified, simple creates all objects,
resolves all object references (obj_ref -> obj. pointers) and sets all
attributes. A specialized "builder" can do more, like adding interfaces for
the entire cluster. I.e. things that are not suitable or impossible to be
defined in XML.

Paul wrote:
> I think one of the most important goals of qemu machine description
> infrastructure is to abstract this kind of detail away from the
> devices.

Such centralization of logic is well suited in a class with the specific
role of easing the "load" of its children. In this case a "builder" class
described above. 

Andreas F wrote:
>True, but XML itself does not allow for arbitrary graphs, only trees.  

Hmm, what kind of graphs could be needed? (Out of curiosity) 

Blue S. wrote:
> OK, so now we have:
> 1 - Fabrice's original proposal
> 2 - Paul's FDT based work
> 3 - Mark's FDT based work
> 4 - Torbjörn's XML based configuration
> 5 - Microsoft XML configuration

I'm honored to be on the list and not last! :)

/BR Torbjörn