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

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Thu, Aug 25, 2011 at 11:04:12AM -0500, Anthony Liguori wrote:
> 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.

No, the point *is* to use DTS. It's an existing format, widely used
and compatible with other tools.

The dtb is passed on by different layers of the boot and is edited for
various reasons, for example to pass on kernel cmd lines. Nothing strange
there.

The reason for removing devices from it, is simply due to lack of manpower,
QEMU doesnt emulate all the devices in the dtb description yet. So that
miss-"feature" will ideally go away with time.

An option is ofcourse to translate the dts to what ever bolibumpa format
qemu is using (with all the compat/versioning issues that brings). Still,
maybe that's something to consider. Peter?


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


Then maybe the FDT machinery could be respinned to work on top of your QOM
objects?

Or are FDT's a complete no go? So external conversion is the only option?

Cheers