Scratch this! I do not think this entry is for the devtree, I think
it is the bogus entry that we create to optionally reserve the memory
for the initrd, this was a side effect of creating the devtree in the
python tree.
So now that its in libxc we can clean it up. We must have made it
redundant because we did not want to leave it as zero, since that
terminates the reservation list.
Here is the patch so far.
+ /* XXX:NB: you MUST set reservations BEFORE
_starting_the_tree_ */
+
This is the redundant entry that allows us to fill in the optional
initrd memory.
We make it first to make it easy to find later, but this should no
longer be necessary.
+ /* root.reserve(0x1000000, 0x1000) */
+ val[0] = cpu_to_be64((u64) 0x1000000);
+ val[1] = cpu_to_be64((u64) 0x1000);
+ ft_add_rsvmap(root, val[0], val[1]);
+
This is the entry that reserves the last 4 pages of the RMA, so
obviously this need to be hang off of rma_bytes as well.
+ /* root.reserve(0x3ffc000, 0x4000 */
+ val[0] = cpu_to_be64((u64) 0x3ffc000);
+ val[1] = cpu_to_be64((u64) 0x4000);
+ ft_add_rsvmap(root, val[0], val[1]);
+
And then there is the implicit terminating entry that is all zeros.
I also notice that:
+ /* xc_linux_load.c will overwrite these 64-bit properties later
+ *
+ * chosen.addprop('linux,initrd-start', long(0))
+ * chosen.addprop('linux,initrd-end', long(0)))
+ */
+ val[0] = cpu_to_be64((u64) 0);
+ ft_prop(root, "linux,initrd-start", val, sizeof(val[0]));
+ ft_prop(root, "linux,initrd-end", val, sizeof(val[0]));
Now that we do this in libcx, we _can_ know the answer and define
them once and even drop the prop and reservation if there _is_ no
initrd.
-JX
On Jan 16, 2007, at 10:13 AM, Jimi Xenidis wrote:
On Jan 16, 2007, at 10:05 AM, Ryan Harper wrote:
* Hollis Blanchard <hollisb@xxxxxxxxxx> [2007-01-15 20:44]:
On Mon, 2007-01-15 at 21:29 -0500, Jimi Xenidis wrote:
On Jan 15, 2007, at 8:20 PM, Hollis Blanchard wrote:
On Mon, 2007-01-15 at 17:25 -0500, Jimi Xenidis wrote:
+int make_devtree(
[snip]
Any ideas what this reservation is for? is it for the flat-
devtree
itself?
Nope.
+ /* root.reserve(0x1000000, 0x1000) */
+ val[0] = cpu_to_be64((u64) 0x1000000);
+ val[1] = cpu_to_be64((u64) 0x1000);
+ ft_add_rsvmap(root, val[0], val[1]);
Yes, it is: see DEVTREE_ADDR in xc_linux_build.c .
so we can lose it, right?
You should know: http://patchwork.ozlabs.org/linuxppc/patch?
id=5043 :)
Yes, we can remove it.
Even though we aren't making the tree in python we are still
loading it
at DEVTREE_ADDR no? Why don't we need it?
First off, the length is bogus.
The reservation list is to let the OS know immediately what memory
the devtree and all it references are occupying. However the
devtree's header contains the real devtree size and the domain is
given its location. So the reservation entry is really redundant
and makes relocating the devtree to an arbitrary location in memory
more difficult.
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel
|
Home