qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Torbjörn Andersson
Subject: [Qemu-devel] Machine description, an alternativ using XML
Date: Thu, 26 Feb 2009 07:49:02 +0100

Greetings!

I, and my collegues, have been using QEMU for some time and we had from the
beginning a need for a more flexible and readable machine definition.
Therefore we developed a solution based on XML with a parser using expat.

I will try to exemplify our solution with a "snip" a ARM INTEGRATOR machine.

<MACHINE name=ARM-INTEGRATOR>
  <OBJECT name="cpu" class="ARM926ej">
    <ATTRIBUTE name="mhz">      <value integer="208"/>  </ATTRIBUTE>
    <ATTRIBUTE name="dtcm_size">        <value integer="8192"/> </ATTRIBUTE>
        <snipp...>
    <ATTRIBUTE name="memmap">   <value obj_ref=":memmap"/>  </ATTRIBUTE>
  </OBJECT>
  <OBJECT name="memmap" class="MEMMAP">
  </OBJECT>
    ....
  <OBJECT name="pic" class="pl190">
    <ATTRIBUTE name="pic">      <value obj_ref=":cpu"/>  </ATTRIBUTE>
    <ATTRIBUTE name="memmap">   <value obj_ref=":memmap"/>  </ATTRIBUTE>
    <ATTRIBUTE name="base">     <value integer="0xc0010000"/>  </ATTRIBUTE>
  </OBJECT>
<MACHINE/>

Firstly, in our solution we call properties attributes. We define
relationships between objects using textual references, with a naming
convention where a name with ':' signals that the name of the target is
relative to the object.
We also have a explicit memmap, all the global variables in exec.c are moved
into a specific QEMU class. There could be several parallel memmaps and
"multi-homed" devices could be attached to several address-spaces.

Our XML files are at QEMU startup parsed by expat and our custom code and we
create an instance of a tree, containing all the information. At the time
the machine is created, a copy of the "template" tree is create and we start
a two-pass traversal of the new tree. We start with creating all the
objects, which enables us to replace all obj_ref values with obj_ptr values
(Pointers to real objects). From this point we can continue with
initializing all our objects, by updating their attributes with the values
in the machine configuration.

I our case, we have found that our "targets" are quite similar, and
therefore we support "clusters" to be defined in XML. Clusters are not
machines but very much alike, an instance of a cluster cannot be the top of
a tree.

All interactions between objects are done through interfaces defined in
h-files. The interfaces and attributes are registered in a "CLASS and
OBJECT" registry that we have added. An object can ask for an interface for
a specific object and the interface is returned, a struct with function
pointers.

I will not try to describe the solution more, because I believe that you now
see what we have built. There is a lot more details that are quite nice. We
defined a inheritance scheme that allows to share even more between
different machines. 

Our question is now: are you interested in this solution? I think we can
quite swiftly provide a patch-set to QEMU where we show the solution in the
ARM-target domain.

I know you are looking at a solution based on FDT. My belief is that the XML
solution is more flexible, but I admit that I know very little about FDT.
Further, I believe that one can create FDTs, from the XML machine
definitions, in runtime and pass them to the target-os if required.

The strong point with the XML solution is that it is very suitable for
modeling embedded systems where lots of GPIOs, interrupts, dma-channels,
i2c, spi, i2s/pcm etc.

I know that this is will result in a large patch set but I think the FDT is
equally big. Further I believe we can have both schemes in QEMU in parallel,
if necessary.

Please take this into consideration. We would be happy to share our solution
with QEMU.

/Best Regards Torbjörn Andersson





reply via email to

[Prev in Thread] Current Thread [Next in Thread]