qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Torbjörn Andersson" <tobbe.tt@home.se>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Machine description, an alternativ using XML
Date: Thu, 26 Feb 2009 07:49:02 +0100	[thread overview]
Message-ID: <004601c997de$50cbd7c0$f2638740$@tt@home.se> (raw)

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	other threads:[~2009-02-26  7:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-26  6:49 Torbjörn Andersson [this message]
2009-02-26 16:06 ` [Qemu-devel] Machine description, an alternativ using XML Paul Brook
2009-02-26 20:26   ` SV: " Torbjörn Andersson
2009-02-26 22:14   ` Anthony Liguori
  -- strict thread matches above, loose matches on Subject: below --
2009-02-26  9:36 Jamie Lokier
2009-02-26 12:01 ` Torbjörn Andersson
2009-02-26 13:24   ` Steve Fosdick
2009-02-26 18:48     ` Andreas Färber
2009-02-26 21:47       ` Jamie Lokier
2009-02-26 19:41 ` Blue Swirl
2009-02-26 13:09 Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='004601c997de$50cbd7c0$f2638740$@tt@home.se' \
    --to=tobbe.tt@home.se \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).