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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home