Re: [Qemu-devel] [RFC PATCH V1 00/14] Dynamic machine model creation from device trees

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/25/2011 10:43 AM, Peter Crosthwaite wrote:
> Hi Anthony,
>
> So the primary motivation for using this is in embedded systems design flows
> where you are already working with DTS for software boot. For
> microblaze-linux, xilinx-ppc and the xilinx-arm platforms which we are
> working with, it even more makes sense as the hardware platform design tools
> are capable of emitting platforms descriptions as DTS. With this framework,
> there is no need to write another description of your system (i.e. a config
> file, or a hardcoded machine model). DTSs are a standardised way of
> describing machines in the embedded linux arena, and are our machine
> description source, so in one way or another, we will continue need to
> create QEMU machines that match a DTB.

Yes, but as is obvious in your series, the DTB used to create the guest 
is not necessarily what you expose to the guest.

So whether the config you use to create the guest is DTB or something 
else sort of doesn't matter.  It's an implementation detail and you 
should be able to easily use any number of formats.

> So anyways, the framework does a little bit more than read-config as the
> framework allows you to define a mapping between dts descriptions and qdev
> device models,

Yes, this is the main problem.  You should be able to do this via a 
programmatic interface (via the monitor).  Really, you should be able to 
do this all via qdev.

> rather than your configuration source being straight up qdev
> property values. There's also examples of more Ad-Hoc device models that are
> not currently qdev models (e.g. pflash_cfi)

That's a bug.  We should convert those devices to qdev, not paper around it.

  where you are forced to take a
> code driven approach rather than have to rely on QDev. It also allows you to
> define machine creation behavior for device nodes that are not QDev devices
> at all (e.g. simple busses or memories).

Another bug.  We should fix those bugs.

> The possibility would exist to take a DTS and to auto-translate it into a
> config format, however the process for doing this would be near identical to
> the code in this patch series, but rather than just straight up instantiate
> the devices as you go, you would have to dump all the results to a single
> data structure then read-config that result i.e:
>
> foo.dtb ->  foo.cfg ->  pass to qemu.
>
> But another important feature of this work that is perhaps glossed over in
> the original description, is the ability to specify opaque interconnection
> data for inter-communicating devices.

This is the goal of QOM except it does this by fixing the problems in 
qdev instead of adding another layer on top of things.

  dtb provides a natural way for devices
> to reference each other and we use this to handle device interconnections
> without interferring with device models.  In the example given, we create
> qemu_irqs for interrupt controllers as they are discovered then tag them as
> opaque data for the interrupt controller fdt_node. When connected device
> instantiate, they cast the opaque data to qemu_irq and connect the
> interrupt. It would be difficult to do this is the two stage process, as you
> would have create directives for managing this opaque data in config files.
>
> Now my understanding is the part of the qdev philosophy is to not embed
> connection information in device models themselves?

No, that's not a philosophy, it's a bug.

Regards,

Anthony Liguori