qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* Re: [Qemu-devel] Machine description, an alternativ using XML
@ 2009-02-26  9:36 Jamie Lokier
  2009-02-26 12:01 ` Torbjörn Andersson
  2009-02-26 19:41 ` Blue Swirl
  0 siblings, 2 replies; 10+ messages in thread
From: Jamie Lokier @ 2009-02-26  9:36 UTC (permalink / raw)
  To: qemu-devel

Torbjörn Andersson wrote:
> <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/>

Why so verbose?

<machine name="arm-integrator">
  <cpu name="cpu0" type="ARM926ej">
     <clock mhz="208"/>
     <dtcm_size>8192</dtcm_size>
     <memmap ref="memmap0"/>
  </cpu>
  <memmap name="memmap0"/>
  <pic name="pic" type="pl190">
     <memmap ref="memmap0"/>
     <cpu ref="cpu0"/>
     <base>0xc0010000</base>
  </pic>
</machine>

> 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.

Isn't FDT capable of that too?

> 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.

If the schemes are equivalently powerful, you can have a converter
which sits outside QEMU.  No need to implement both inside QEMU.
People do this already, converting config files to QEMU command line
options.

Fwiw, Microsoft Virtual PC uses an XML file to describe the machine
and it makes sense to me.

Here's an example from a real VPC machine.  Hmm, maybe it's a bit long.
Is the equivalent FDT any clearer or shorter, though?

-- Jamie



<?xml version="1.0" encoding="UTF-16"?>
<!-- Microsoft Virtual Machine Options and Settings -->
<preferences>
    <version type="string">2.0</version>
    <alerts>
        <notifications>
            <no_boot_disk type="boolean">true</no_boot_disk>
        </notifications>
    </alerts>
    <hardware>
        <memory>
            <ram_size type="integer">512</ram_size>
        </memory>
        <pci_bus>
            <ethernet_adapter>
                <controller_count type="integer">1</controller_count>
                <ethernet_controller id="0">
                    <virtual_network>
                        <id type="bytes">12341234123412341234123412341234</id>
                        <name type="string">Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller</name>
                    </virtual_network>
                    <ethernet_card_address type="bytes">000123456789</ethernet_card_address>
                </ethernet_controller>
            </ethernet_adapter>
            <video_adapter>
                <vram_size type="integer">8</vram_size>
            </video_adapter>
            <ide_adapter>
                <ide_controller id="1">
                    <location id="0">
                        <drive_type type="integer">2</drive_type>
                        <pathname>
                            <absolute type="string">\\srv\Develop\Software\MS SQL Eval\SQLEVAL.ISO</absolute>
                            <relative type="string" />
                        </pathname>
                    </location>
                </ide_controller>
                <ide_controller id="0">
                    <location id="0">
                        <drive_type type="integer">1</drive_type>
                        <pathname>
                            <absolute type="string">C:\Documents and Settings\test\My Documents\My Virtual Machines\test\test Hard Disk.vhd</absolute>
                            <relative type="string">.\test Hard Disk.vhd</relative>
                        </pathname>
                        <undo_pathname>
                            <absolute type="string" />
                            <relative type="string" />
                        </undo_pathname>
                    </location>
                </ide_controller>
            </ide_adapter>
        </pci_bus>
        <standard>
            <name type="string">Virtual PC 2007</name>
            <version type="string">0001.0000.0000</version>
        </standard>
        <super_io>
            <floppy id="0">
                <pathname>
                    <absolute type="string" />
                    <relative type="string" />
                </pathname>
            </floppy>
            <floppy>
                <auto_detect type="boolean">true</auto_detect>
            </floppy>
            <parallel_port>
                <port_shared type="boolean">false</port_shared>
                <port_type type="integer">0</port_type>
            </parallel_port>
            <serial_port>
                <connect_immediately type="boolean">false</connect_immediately>
            </serial_port>
        </super_io>
        <bios>
            <base_board>
                <serial_number type="string">8886-9141-1653-9060-4025-7842-65</serial_number>
            </base_board>
            <bios_guid type="string">{125BDA48-420C-446E-AA48-9B597632229C}</bios_guid>
            <bios_serial_number type="string">8886-9141-1653-9060-4025-7842-65</bios_serial_number>
            <chassis>
                <asset_tag type="string">8886-9141-1653-9060-4025-7842-65</asset_tag>
                <serial_number type="string">8886-9141-1653-9060-4025-7842-65</serial_number>
            </chassis>
            <cmos type="bytes">00004000F0223F8002FFFF2F00FF3F1000003F00000000000031004C070707070666FFFF208580FF01000000200C01800CF400000000000000000000000000901A32E24A580050E999E62401002784004A2080240000000000085AACFE1032547698BAE400000000000003000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000</cmos>
            <time_bytes type="bytes">42004800120002290408</time_bytes>
        </bios>
    </hardware>
    <integration>
        <microsoft>
            <mouse>
                <allow type="boolean">true</allow>
            </mouse>
            <video>
                <user_selected>
                    <depth type="integer">16</depth>
                    <height type="integer">480</height>
                    <width type="integer">640</width>
                </user_selected>
            </video>
            <version>
                <additions_number type="string">013803</additions_number>
                <guest_os>
                    <build_number type="string">5.02.3790</build_number>
                    <long_name type="string">Microsoft Windows Server 2003</long_name>
                    <revision_number type="string">Service Pack 2</revision_number>
                    <short_name type="string">Windows Server 2003</short_name>
                    <suite_name type="string">Server</suite_name>
                </guest_os>
            </version>
        </microsoft>
    </integration>
    <properties>
        <creator>
            <build type="string">6.0.156.0</build>
            <name type="string">Microsoft Virtual PC 2007</name>
        </creator>
        <modifier>
            <build type="string">6.0.156.0</build>
            <name type="string">Microsoft Virtual PC 2007</name>
        </modifier>
    </properties>
    <settings>
        <shutdown>
            <prompt type="boolean">true</prompt>
            <quit>
                <action type="integer">4</action>
                <was_running type="boolean">false</was_running>
            </quit>
            <save>
                <enable type="boolean">true</enable>
            </save>
            <shutdown>
                <enable type="boolean">true</enable>
            </shutdown>
            <turn_off>
                <enable type="boolean">true</enable>
            </turn_off>
            <last_shutdown>
                <choice type="integer">0</choice>
                <commit type="boolean">true</commit>
            </last_shutdown>
        </shutdown>
        <sound>
            <sound_adapter>
                <enable type="boolean">true</enable>
            </sound_adapter>
        </sound>
        <startup>
            <automatic>
                <type type="integer">2</type>
            </automatic>
        </startup>
        <undo_drives>
            <enabled type="boolean">false</enabled>
            <purposely_kept type="boolean">false</purposely_kept>
            <use_default type="boolean">true</use_default>
        </undo_drives>
        <video>
            <disable_resize type="boolean">false</disable_resize>
            <full_screen type="boolean">false</full_screen>
            <mode>
                <full_screen>
                    <startup type="boolean">false</startup>
                </full_screen>
            </mode>
            <resolutions>
                <standard_only type="boolean">false</standard_only>
            </resolutions>
            <height type="integer">768</height>
            <left_position type="integer">1361</left_position>
            <max_height type="integer">768</max_height>
            <max_width type="integer">1024</max_width>
            <top_position type="integer">58</top_position>
            <width type="integer">1024</width>
        </video>
        <guest_os type="integer">6</guest_os>
    </settings>
    <virtual_machines>
        <hw_assist>
            <enable_hw_assist type="boolean">true</enable_hw_assist>
        </hw_assist>
    </virtual_machines>
</preferences>

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [Qemu-devel] Machine description, an alternativ using XML
@ 2009-02-26 13:09 Jamie Lokier
  0 siblings, 0 replies; 10+ messages in thread
From: Jamie Lokier @ 2009-02-26 13:09 UTC (permalink / raw)
  To: qemu-devel

Torbjörn Andersson wrote:
> Jamie Lokier Wrote:
> > > <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/>
> > 
> > Why so verbose?
> > 
> > <machine name="arm-integrator">
> >   <cpu name="cpu0" type="ARM926ej">
> >      <clock mhz="208"/>
> >      <dtcm_size>8192</dtcm_size>
> >      <memmap ref="memmap0"/>
> >   </cpu>
> >   <memmap name="memmap0"/>
> >   <pic name="pic" type="pl190">
> >      <memmap ref="memmap0"/>
> >      <cpu ref="cpu0"/>
> >      <base>0xc0010000</base>
> >   </pic>
> > </machine>
> 
> We aimed for not putting any aditional burdon on QEMU, by defining concepts
> like PIC and MEMMAP. Simply Objects and Classes should exist. Then we added
> MACHINES and CLUSTERS as types in the XML files.

That doesn't make sense.  QEMU needs to know about PICs and MEMMAPs
whatever syntax it uses.

> > Fwiw, Microsoft Virtual PC uses an XML file to describe the machine
> > and it makes sense to me.
> 
> Very readable. But, I dislike the complex DTD, which needs to be maintained
> when new machine designs arrive. I believe that Classes and Objects, with
> relationships, is enough.

That's just a DTD at a different level: hard-coded in the program's
parsing of Classes, Objects and Attributes.

Presumably you want a generic, simple DTD so that you can use some
handy generic XML tools and libraries.

But your tools need to know about PICs and MEMMAPs too.  By hiding it
in Classes and Objects, you force the "real" DTD to be hard-coded into
multiple tools at the semantic level, including object-relationship
checking (that each PIC has exactly one CPU, for example).  In other
words, preventing generic XML tools from doing anything useful :-)

There's abstraction and there's being verbose with no gain.  That's
not smart XML, and it's not human friendly either.

If you don't want to write a DTD, that's ok just don't write a DTD.

> Imagine defining a AMP system, not SMP, in VPC. How can we define AMP
> machines in FDT? I'm running targets with two CPUs with separate address
> spaces and need to do that in the future too.

No idea :-)

If FDT can't do it, then it's not suitable.  If it can be hacked in
but it's very messy, than I think it's barely suitable and we'll all
be using a wrapper tool to hide it, which is silly.

-- Jamie

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [Qemu-devel] Machine description, an alternativ using XML
@ 2009-02-26  6:49 Torbjörn Andersson
  2009-02-26 16:06 ` Paul Brook
  0 siblings, 1 reply; 10+ messages in thread
From: Torbjörn Andersson @ 2009-02-26  6:49 UTC (permalink / raw)
  To: qemu-devel

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

^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-02-26 22:14 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-26  9:36 [Qemu-devel] Machine description, an alternativ using XML 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
  -- strict thread matches above, loose matches on Subject: below --
2009-02-26 13:09 Jamie Lokier
2009-02-26  6:49 Torbjörn Andersson
2009-02-26 16:06 ` Paul Brook
2009-02-26 22:14   ` Anthony Liguori

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).