[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.