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

* 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?

> 
> > {
> >     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?

> 
> >     unsigned long initrd_end = initrd_base + initrd_len;
> >     int64_t shadow_mb_log;
> >     uint64_t pft_size;
> >@@ -332,6 +335,9 @@ int make_devtree(struct ft_cxt *root,
> >     char *cpuname = NULL;
> >     int saved_errno;
> >     int dtb_fd = -1;
> >+    uint64_t shared_info_addr = (rma_bytes - PAGE_SIZE);
> >+    uint64_t store_mfn = (rma_bytes - (2*PAGE_SIZE)) >> PAGE_SHIFT;
> >+    uint64_t console_mfn = (rma_bytes - (3*PAGE_SIZE)) >> PAGE_SHIFT;
> 
> as above.. not MFNs

See my comment above.

> >     /*  xen.addprop('version', 'Xen-3.0-unstable\0') */
> >     ft_prop_str(root, "version", "Xen-3.0-unstable");
> 
> This property should be called "compatible"

OK.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@xxxxxxxxxx

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