WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [XenPPC] [PATCH 1/3] libxc: add start_info_t node to devtree


On Jan 25, 2007, at 3:16 PM, Ryan Harper wrote:

* Jimi Xenidis <jimix@xxxxxxxxxxxxxx> [2007-01-25 13:57]:
Thanks _a_lot_ Ryan.. this stuff is really tedious.
Just a few more things.

BTW: what about start_info->flags = SIF_PRIVILEGED or
SIF_INITDOMAIN.  You will not need properties now but you will need
to make sure there absence is recognized in linux/.../setup.c.

OK, I'll take a look.

Signed-off-by: Ryan Harper <ryanh@xxxxxxxxxx>
---
diff -r ed5ee9dde0bd tools/libxc/powerpc64/mk_flatdevtree.c
--- a/tools/libxc/powerpc64/mk_flatdevtree.c    Sun Jan 21 08:17:46
2007 -0500
+++ b/tools/libxc/powerpc64/mk_flatdevtree.c    Thu Jan 25 11:57:41
2007 -0600
@@ -316,13 +316,16 @@ int make_devtree(struct ft_cxt *root,
                 unsigned long shadow_mb,
                 unsigned long initrd_base,
                 unsigned long initrd_len,
-                 const char *bootargs)
+                 const char *bootargs,
+                 unsigned long console_evtchn,
+                 unsigned long store_evtchn,
+                 unsigned long nr_pages)
nr_pages no long needed

Right.



Since you later look for the console_mfn and store_mfn later, it
would be better in the caller and pass then in.
FYI: It is xend that decides where store and console go. shared_info
is a hypervisor contract so you can continue to calculate it here if
you want.

Also the devtree should not contain MFNs for frame numbers of any
kind, simply addresses.

I don't follow. the start_info_t structure explicitly wants an mfn, how
else am I suppose to fill that value out in linux?

they are MFNs on x86, in PPC they are domain physical addresses.



{
    struct boot_param_header *bph = NULL;
    uint64_t val[2];
    uint32_t val32[2];
    unsigned long remaining;
-    unsigned long rma_reserve = 4 * PAGE_SIZE;
+    unsigned long rma_reserve = 3 * PAGE_SIZE;

base this on MIN(store, console)

Why? Don't we always have a store and a console page?

yes we do, but they could be in any order, all you are trying to do is make sure the pages are in the reserve map. Another possibility is you could not assume contiguity and create a reservation entry for each of the three pages.

-JX



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