qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Machine description as data


From: David Gibson
Subject: Re: [Qemu-devel] [RFC] Machine description as data
Date: Fri, 13 Feb 2009 12:00:03 +1100
User-agent: Mutt/1.5.18 (2008-05-17)

On Thu, Feb 12, 2009 at 11:52:42AM -0600, Hollis Blanchard wrote:
> On Thu, 2009-02-12 at 11:26 +0100, Markus Armbruster wrote:
> >  David Gibson <address@hidden> writes:
> > 
> > > On Wed, Feb 11, 2009 at 12:50:28PM -0600, Hollis Blanchard wrote:
> > >> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
> > > [snip]
> > >> > I briefly examined the DT source format and the tree structure it
> > >> > describes for the purpose of QEMU configuration.  I decided
> > against
> > >> > using it in my prototype because I found it awfully low-level and
> > >> > verbose for that purpose (I'm sure it serves the purpose it was
> > designed
> > >> > for just fine).  Issues include:
> > >> > 
> > >> > * Since the DT is designed for booting kernels, not configuring
> > QEMU,
> > >> >   there's information that has no place in QEMU configuration,
> > and
> > >> >   required QEMU configuration isn't there.
> > >> 
> > >> What's needed is a "binding" in IEEE1275-speak: a document that
> > >> describes qemu-specific nodes/properties and how they are to be
> > >> interpreted.
> > >> 
> > >> As an example, you could require that block devices contain
> > properties
> > >> named "qemu,path", "qemu,backend", etc.
> > >
> > > Yes, it shouldn't be hard to annotate an IEEE1275 style tree with
> > > extra information for qemu's use.
> > 
> > I don't feel up to that task, because I'm not really familiar with
> > IEEE1275.  Could you help out?
> 
> I'm not really a "language lawyer" for device trees, but I can help.
> 
> FWIW, I was imagining (from a PowerPC point of view) that a strict
> subset of the device tree interpreted by qemu would be passed into the
> guest. In other words, once qemu is done with it, it would strip every
> property prefixed with "qemu," and copy the result into guest memory.
> PowerPC kernels require this data structure, and even when firmware runs
> in the guest, you still need to tell the firmware what the system layout
> is, and the device tree is an obvious candidate...

I wouldn't actually bother stripping the "qemu,..." properties.  They
should be ignored by the OS anyway.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson




reply via email to

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