[Qemu-devel] Machine config files

[David Gibson]

On Fri, Nov 14, 2008 at 01:51:40PM -0600, Hollis Blanchard wrote:
> On Friday 14 November 2008 13:29:12 Anthony Liguori wrote:
> > Blue Swirl wrote:
> > > On 11/14/08, Paul Brook <paul at codesourcery.com> wrote:
> > >   
> > >> It's come up in other contexts recently, so I think it's worth mentioning 
> that
> > >>  I am currently working on adding a machine config file support to qemu.
> > >>
> > >>  I am focusing on the board setup side of things, rather than the 
> user-level
> > >>  config side.  My goal is to come up with a system that will allow e.g. 
> the
> > >>  entirety of realview.c and gumstix.c to be eliminated.  Currently this 
> is
> > >>  based this round Flattened Device Trees (as used by ppc-linux).
> > >>
> > >>  I have looked at the bits that Fabrice did a while ago. While that 
> contains
> > >>  some good ideas (which I will probably steal!) it is approaching the 
> problem
> > >>  from a somewhat different direction.  FTDs are a much better fit for 
> some of
> > >>  my requirements (e.g. being able to pass the config through to the guest 
> OS).
> > >>     
> > >
> > > libfdt looks like an excellent choice for both Sparc32 and Sparc64, I
> > > think the whole OF tree can be represented with it.
> > >
> > > The config could be passed using the firmware configuration device.
> > >   
> > 
> > I was looking through libfdt too.  I think it could also be used for 
> > x86.  Hollis, I was looking through the Bamboo code, any reason you 
> > don't describe the bus/device layouts in the DTS and then use that to 
> > determine what bus/nic to add?
> 
> We do; PLB, OPB, and EBC are all on-chip busses found on IBM PowerPC SoCs. For 
> example, you can see devices representing the UARTs and PCI controller in our 
> bamboo.dts file. Qemu only modifies the device tree at runtime with 
> information not known until then (memory size, clock frequency, etc).
> 
> You may mean why don't we enumerate *PCI* devices in the device tree. Since 
> libfdt is used for embedded systems, this is a tradeoff that allows us to 
> keep the device tree smaller -- why put lots of PCI nodes in the device tree, 
> when the OS can easily discover them itself? That said, PCI devices are 
> indeed found in the device tree in IBM Power servers; Linux just doesn't 
> require them.

Yes, in general the rule is that devices on busses that can be runtime
probed - PCI, USB and the like - don't typically need to appear in a
flattened device tree (though they would traditionally appear in a
full Open Firmware device tree).  Only the things the OS has to "just
know" are there need appear - e.g. on-chip devices, hardwarired
on-board devices, unprobeable legacy ISA devices, usually the PCI host
bridge, and so forth.

Nodes for probeable devices may optionally appear, and in certain
cases they must appear to supply bits of information that can't be
probed.  For example, on-board PCI devices often have interrupts
routed directly to the system PIC, rather than going across the PCI
bus.  In this case a device node would need to appear with the
interrupt routing information.

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