[XenPPC] DomU device tree plan

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

I think I have all our trees sorted now (and we should be all up-to-date
again), so I've been working on device tree construction again...

As a very brief recap, we're looking at how best to construct the device
tree when constructing a new DomU.

At the Xen minisummit in Ottawa, Ewan recommended constructing the
device tree in python, since the xend level of the tools has access to
information like total memory size, virtual IO devices, etc. Also, it
will be easier to mine information like timebase-frequency from dom0's
device tree (to pass in to domU) from python than from C.

Oh, did I mention we're looking to use a flattened device tree? That way
we can omit the OF client interface firmware code we currently load into
domUs. (We could still supply a client interface for other OSs in the
future, if needed, and that code would interpret the flattened tree
itself.)

So I've got some python that can create a flattened tree. The only catch
is that some information, notably the console_mfn and store_mfn, is
*returned* from libxc to python, so we can't actually insert that
information into the tree from python before calling libxc.

I see a couple options:
1. Write a bunch of flat tree to have libxc parse and insert /xen/*_mfn
properties. That could involve refactoring dtc, which may be unpleasant,
or just hacking up our own.
2. Create empty /xen/*_mfn properties in python, and then overwrite them
in libxc. Probably easier than 1.
3. Change the libxc interface somehow to allow xend to pass the mfn
parameters to libxc and not the other way around. I haven't investigated
this one yet; I'm not sure if that will work out for x86/ia64.

This is just an FYI, but comments are welcome.

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel