On Jul 28, 2006, at 6:07 PM, Hollis Blanchard wrote:

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.
Not sure we would ever do Virtual IO in the devtree, all that discovery is so XenStore/Bus right now it may be hard to decouple.

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.

I agree, python should certainly make it easier to "suck up" /proc/ device-tree "nodes" into the devtree.

So I've got some python that can create a flattened tree.

Caution: I say this only because I have yet to see the python interfaces Hollis is writing. This could be a lot of work, the devtree is a difficult WOS (Wad O' Stuff), things like properties that are "backreferences" to nodes that may or may not have been created yet. It may be difficult to get this right, we need to be careful how much we invest in new code to handle this, when perhaps existing tools may be invested in.


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.

Classically console_mfn, store_mfn are "allocated" from the memory of the new domain by libxc, by allocated I mean they are "chosen", example:
  x86_*: they are the next pages after all images are loaded.
  ia64: they are the first few pages of domain memory.
  ppc: the last few pages of the RMA

The shared_info page can com from "Xen Space" and the domain is allowed to map it, on PPC it is always the last page of the RMA.

We make sure that these pages are in the RMA so we can access them in real mode, particularly the console_mfn and event channel array.

So there is really no reason that the python layer cannot define these, the current definition libxc definition are a hack anyway. Once we go beyond RMA we will need to teach the python layers about RMA.

The only real issue is the ramdisk, libxc currently decides where it is, and you need some rudimentary elf parsing to figure out where to actually put it, but ultimately its location and size need to be in the devtree:
  /chosen/linux,initrd-start
  /chosen/linux,initrd-end

We also need to consider that as we hotplug things they will end up in the the DomU's /proc/device-tree and on reboot, checkpoint or migration, we will need to make sure that all this information is preserved and recreated. Whether thats thru another flattened devtree, or a devtree created from some other Xen specific "state" file.


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.

For completeness, there is a 4th option:
4. Have the python create an ascii file that is the source file DTS for a tool called the Device Tree Compiler. Then have the python exec the DTC to create the devtree

The problem with 4 is that it is unclear what the future of the DTC is, some people in embedded are using it but its not part of any distro, it does not seem to be embraced by the kexec community and its yet another orthogonal package we will have to maintain.

Personally, I like the DTC, but until the linuxPPC community is willing to stand and fully depend on it, I cannot expect the XenPPC community to.

-JX

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

Reply via email to