[XenPPC] [PATCH] [UPDATE] Xencomm optimzation to work for modules
This patch should address all the issues Jimi has pointed out.
Now has been successfully tested boothing as dom0 & loading VIO modules
with DOMU.
If a structure that does not fit within 1 page is pointed to, we need
to create a structure on the stack to represent this structure for the
hypervisor. This code affects kernel module addresses which are do not
have physically contiguous memory.
Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Tue Dec 19 09:22:37 2006 -0500
+++ b/arch/powerpc/platforms/xen/gnttab.c Wed Jan 26 01:06:39 2028 -0600
@@ -263,8 +263,10 @@ int HYPERVISOR_grant_table_op(unsigned i
memcpy(&setup, op, sizeof(setup));
argsize = sizeof(setup);
- frame_list = xencomm_create_inline(
- xen_guest_handle(setup.frame_list));
+ frame_list = xencomm_map(
+ xen_guest_handle(setup.frame_list),
+ (sizeof(*xen_guest_handle(setup.frame_list))
+ * setup.nr_frames));
set_xen_guest_handle(setup.frame_list, frame_list);
memcpy(op, &setup, sizeof(setup));
@@ -286,7 +288,7 @@ int HYPERVISOR_grant_table_op(unsigned i
return -ENOSYS;
}
- desc = xencomm_create_inline(op);
+ desc = xencomm_map_early(op, argsize);
ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
desc, count);
diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Tue Dec 19 09:22:37 2006 -0500
+++ b/arch/powerpc/platforms/xen/hcall.c Wed Jan 26 02:53:15 2028 -0600
@@ -54,7 +54,7 @@
int HYPERVISOR_console_io(int cmd, int count, char *str)
{
- void *desc = xencomm_create_inline(str);
+ void *desc = xencomm_map_early(str, count);
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_console_io),
cmd, count, desc);
@@ -63,14 +63,14 @@ EXPORT_SYMBOL(HYPERVISOR_console_io);
int HYPERVISOR_event_channel_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
+ void *desc = xencomm_map_early(op, sizeof(evtchn_op_t));
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
cmd, desc);
}
EXPORT_SYMBOL(HYPERVISOR_event_channel_op);
-int HYPERVISOR_xen_version_userspace(int cmd, void *arg)
+int HYPERVISOR_xen_version(int cmd, void *arg)
{
struct xencomm_desc *desc;
const unsigned long hcall = __HYPERVISOR_xen_version;
@@ -107,29 +107,20 @@ int HYPERVISOR_xen_version_userspace(int
return -ENOSYS;
}
- rc = xencomm_create(arg, argsize, &desc, GFP_KERNEL);
- if (rc)
- return rc;
-
- rc = plpar_hcall_norets(XEN_MARK(hcall), cmd, xencomm_pa(desc));
-
- xencomm_free(desc);
+ desc = xencomm_map_early(arg, argsize);
+ if (desc == NULL)
+ return -1;
+
+ rc = plpar_hcall_norets(XEN_MARK(hcall), cmd, desc);
+
return rc;
}
EXPORT_SYMBOL(HYPERVISOR_xen_version);
-int HYPERVISOR_xen_version(int cmd, void *arg)
-{
- if (is_kernel_addr((unsigned long)arg)) {
- void *desc = xencomm_create_inline(arg);
- return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_xen_version), cmd, desc);
- }
- return HYPERVISOR_xen_version_userspace(cmd, arg);
-}
int HYPERVISOR_physdev_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
+ void *desc = xencomm_map_early(op, sizeof(physdev_op_t));
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_physdev_op),
cmd, desc);
@@ -138,6 +129,7 @@ EXPORT_SYMBOL(HYPERVISOR_physdev_op);
int HYPERVISOR_sched_op(int cmd, void *arg)
{
+ int argsize = 0;
struct xencomm_desc *desc;
switch (cmd) {
@@ -151,24 +143,30 @@ int HYPERVISOR_sched_op(int cmd, void *a
evtchn_port_t *ports;
struct sched_poll sched_poll;
+ argsize = sizeof(struct sched_poll);
+
memcpy(&sched_poll, arg, sizeof(sched_poll));
- ports = xencomm_create_inline(
- xen_guest_handle(sched_poll.ports));
+ ports = xencomm_map(
+xen_guest_handle(sched_poll.ports),
+(sizeof(evtchn_port_t) * sched_poll.nr_ports));
set_xen_guest_handle(sched_poll.ports, ports);
memcpy(arg, &sched_poll, sizeof(sched_poll));
}
break;
case SCHEDOP_shutdown:
+ argsize = sizeof(struct sched_shutdown);
+ break;
case SCHEDOP_remote_shutdown:
+ argsize = sizeof(struct sched_remote_shutdown);
break;
default:
printk(KERN_ERR "%s: unknown sched op %d\n", __func__, cmd);
return -ENOSYS;
}
- desc = xencomm_create_inline(arg);
+ desc = xencomm_map_early(arg, argsize);
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
cmd, desc);
@@ -234,7 +232,7 @@ static int xenppc_privcmd_domctl(privcmd
xen_domctl_t kern_op;
xen_domctl_t __user *user_op = (xen_domctl_t __user *)hypercall->arg[0];
struct xencomm_desc *op_desc;
- struct xencomm_desc *desc = NULL;
+ void *desc = NULL;
int ret = 0;
if (copy_from_user(&kern_op, user_op, sizeof(xen_domctl_t)))
@@ -246,9 +244,9 @@ static int xenppc_privcmd_domctl(privcmd
return -EACCES;
}
- ret = xencomm_create(&kern_op, sizeof(xen_domctl_t), &op_desc, GFP_KERNEL);
- if (ret)
- return ret;
+ op_desc = x
[XenPPC] Question about netbooting with initrd/initramfs
I've been having some trouble netbooting linux on a JS21 with an initramfs, and wanted to see if there were any known issues, etc. Are there any difficulties in netbooting as an image on a JS21 with an initramfs/initrd? Any secret voodoo? I'm using Maria's branch of the linux-ppc kernel both on bare-metal, and on Xen, and I netboot both. Since I've successfully compiled the Dom0 kernel into Xen, so am just concerned with the step of getting the initramfs into the linux kernel. I've followed the instructions straight from the xensource powerpc wiki for building an initrd. I've also tried compiling using the specify initramfs source config option in the build process. I can successfully boot with an initramfs using yaboot, if I specify an option for it, but I have not successfully booted with an initial image over netboot, or through yaboot with all the bootargs compiled into the kernel. Any help or pointers are appreciated. Thanks David Daly Research Staff Member 32-003 IBM T.J. Watson Research Center Yorktown Heights, NY, 10958 (914) 945-1845, T/L 862-1845___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 1/3] libxc: add start_info_t node to devtree
On Jan 25, 2007, at 3:51 PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-25 14:40]:
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.
Maybe I've just got it named funny, I don't know. And I'm still
confused as to what you want me to put in?
I'm suggesting that we do not use a frame number in the devtree but
use the address that the frame number represents.
On PPC, MFN is a misnomer, this value is not an MFN but a domain PFN
(that is the page belongs to the domain), its just a bad name for us
because the structure is for x86. Later (on PPC) we convert the
domain PFN to and phys addr.
The value that I put in start_info->console.domU.mfn is:
((rma_pages << 12) - (2*PAGE_SIZE)) >> PAGE_SHIFT
where rma_pages = (1 << 26) >> PAGE_SHIFT
the resulting value is 0x3ffe. Is this value correct and I just
have an
incorrect name for it (mfn)?
yes
Am I getting lucky? I've tested the
patches and dom0 and domU boot.
Not luck, we just preserved a crappy name for a crappy struct that in
PPC land will dissapear.
{
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.
I don't understand what is wrong with the above. We are reserving the
last X pages of the RMA. 1 for shared_info, 1 for console, one for
store. I futher don't understand what the value MIN(store,console)
gives me. Sorry for being dense here.
I know it is confusing, thats why it is so important we get it right.
First, I suggested that you pass in these addresses.
Once they are passed in, this function has no idea which one has the
lowest address.
There is nothing from stoping from changing the order of these 2
pages, as long as both sides agree.
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] xend: Don't ignore shadow memory requirement
pushed, thanks ryan -JX On Jan 25, 2007, at 2:32 PM, Ryan Harper wrote: We don't need a custom buildDomain() anymore but we do need to provide a shadow memory calculation. - Create PPC_LinuxImageHandler class to implement getRequiredShadowMemory(). - Derive prose builder from PPC_LinuxImageHandlerClass. - Drop configure() as it is not needed according to Jimi. Signed-off-by: Ryan Harper <[EMAIL PROTECTED]> ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 1/3] libxc: add start_info_t node to devtree
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-25 14:40]:
> >>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.
Maybe I've just got it named funny, I don't know. And I'm still
confused as to what you want me to put in?
The value that I put in start_info->console.domU.mfn is:
((rma_pages << 12) - (2*PAGE_SIZE)) >> PAGE_SHIFT
where rma_pages = (1 << 26) >> PAGE_SHIFT
the resulting value is 0x3ffe. Is this value correct and I just have an
incorrect name for it (mfn)? Am I getting lucky? I've tested the
patches and dom0 and domU boot.
>
> >
> >>
> >>>{
> >>>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.
I don't understand what is wrong with the above. We are reserving the
last X pages of the RMA. 1 for shared_info, 1 for console, one for
store. I futher don't understand what the value MIN(store,console)
gives me. Sorry for being dense here.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/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 <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]>
---
diff -r ed5ee9dde0bd tools/libxc/powerpc64/mk_flatdevtree.c
--- a/tools/libxc/powerpc64/mk_flatdevtree.cSun Jan 21 08:17:46
2007 -0500
+++ b/tools/libxc/powerpc64/mk_flatdevtree.cThu 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@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 1/3] libxc: add start_info_t node to devtree
* Jimi Xenidis <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]>
> >---
> >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
[EMAIL PROTECTED]
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 1/3] libxc: add start_info_t node to devtree
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.
On Jan 25, 2007, at 2:16 PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-24 12:42]:
The data that was in start_info_t should be just simple bindings
in "/
xen" since they describe xen, there is no need to create a new node.
many of the props are not needed since they are expressed elsewhere
in the devtree or perhaps differently.
more below.
New rev:
-dropped /xen/start_info_t, hanging new node /xen/store
-fixed up /xen/console/reg to be proper value
-fixed up /xen/console/interrupts to use value passed from xend
-renamed property 'shared_info' to 'shared-info'
-fixed 'shared-info' to be a proper value
-reduced the number of pages reserved at the end of RMA from 4 to 3
as we no longer need to reserve a page for start_info_t
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
mk_flatdevtree.c | 45 +++--
mk_flatdevtree.h |6 ++-
xc_linux_build.c | 83 +
+-
3 files changed, 80 insertions(+), 54 deletions(-)
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
---
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
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.
{
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)
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
uint32_t cpu0_phandle = get_phandle();
uint32_t xen_phandle = get_phandle();
uint32_t rma_phandle = get_phandle();
@@ -419,11 +425,6 @@ int make_devtree(struct ft_cxt *root,
/* xen = root.addnode('xen') */
ft_begin_node(root, "xen");
-/* start-info is the first page in the RMA reserved area */
-val[0] = cpu_to_be64((u64) (rma_bytes - rma_reserve));
-val[1] = cpu_to_be64((u64) PAGE_SIZE);
-ft_prop(root, "start-info", val, sizeof(val));
-
/* xen.addprop('version', 'Xen-3.0-unstable\0') */
ft_prop_str(root, "version", "Xen-3.0-unstable");
This property should be called "compatible"
@@ -432,6 +433,11 @@ int make_devtree(struct ft_cxt *root,
val[1] = cpu_to_be64((u64) 0);
ft_prop(root, "reg", val, sizeof(val));
+/* point to shared_info_t page base addr */
+val[0] = cpu_to_be64((u64) shared_info_addr);
+val[1] = cpu_to_be64((u64) PAGE_SIZE);
+ft_prop(root, "shared-info", val, sizeof(val));
+
/* xen.addprop('domain-name', imghandler.vm.getName() + '\0') */
/* libxc doesn't know the domain name, that is purely a xend
thing */
/* ft_prop_str(root, "domain-name", domain_name); */
@@ -442,12 +448,33 @@ int make_devtree(struct ft_cxt *root,
/* xencons = xen.addnode('console') */
ft_begin_node(root, "console");
-/* xencons.addprop('interrupts', 1, 0) */
-val32[0] = cpu_to_be32((u32) 1);
+/* console_mfn */
+val[0] = cpu_to_be64((u64) console_mfn);
address
+val[1] = cpu_to_be64((u64) PAGE_SIZE);
+ft_prop(root, "reg", val, sizeof(val));
+
+/* xencons.addprop('interrupts', console_evtchn, 0) */
+val32[0] = cpu_to_be32((u32) console_evtchn);
val32[1] = cpu_to_be32((u32) 0);
ft_prop(root, "interrupts", val32, sizeof(val32));
/* end of consol
[XenPPC] [PATCH] xend: Don't ignore shadow memory requirement
In the process of syncing our python with xen-unstable I eliminated the
PPC_LinuxImageHandler class as we can now use the generic handler since
we create the devtree in libxc. However, we still need to provide a
shadow memory calculation. This patch restores the class and implements
the getRequiredShadowMemory() method. This eliminates the following
message from xen:
(XEN) shadow_set_allocation: WARNING!!: Update your managment tools
The prose builder now derives itself from the restore class. Jimi
mentioned that the configure() method in the prose class can be dropped.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
image.py | 32 +++-
1 files changed, 15 insertions(+), 17 deletions(-)
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
---
We don't need a custom buildDomain() anymore but we do need to provide a
shadow memory calculation.
- Create PPC_LinuxImageHandler class to implement
getRequiredShadowMemory().
- Derive prose builder from PPC_LinuxImageHandlerClass.
- Drop configure() as it is not needed according to Jimi.
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
diff -r b6751137c3c4 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.pyThu Jan 25 13:18:37 2007 -0600
+++ b/tools/python/xen/xend/image.pyThu Jan 25 13:20:37 2007 -0600
@@ -214,15 +214,22 @@ class LinuxImageHandler(ImageHandler):
ramdisk= self.ramdisk,
features = self.vm.getFeatures())
-
-
-class PPC_ProseImageHandler(LinuxImageHandler):
+class PPC_LinuxImageHandler(LinuxImageHandler):
+
+ostype = "linux"
+
+def getRequiredShadowMemory(self, shadow_mem_kb, maxmem_kb):
+"""@param shadow_mem_kb The configured shadow memory, in KiB.
+@param maxmem_kb The configured maxmem, in KiB.
+@return The corresponding required amount of shadow memory, also in
+KiB.
+PowerPC currently uses "shadow memory" to refer to the hash table."""
+return max(maxmem_kb / 64, shadow_mem_kb)
+
+
+class PPC_ProseImageHandler(PPC_LinuxImageHandler):
ostype = "prose"
-
-def configure(self, vmConfig, imageConfig, deviceConfig):
-LinuxImageHandler.configure(self, vmConfig, imageConfig, deviceConfig)
-self.imageConfig = imageConfig
def buildDomain(self):
store_evtchn = self.vm.getStorePort()
@@ -248,15 +255,6 @@ class PPC_ProseImageHandler(LinuxImageHa
cmdline= self.cmdline,
ramdisk= self.ramdisk,
features = self.vm.getFeatures())
-
-def getRequiredShadowMemory(self, shadow_mem_kb, maxmem_kb):
-"""@param shadow_mem_kb The configured shadow memory, in KiB.
-@param maxmem_kb The configured maxmem, in KiB.
-@return The corresponding required amount of shadow memory, also in
-KiB.
-PowerPC currently uses "shadow memory" to refer to the hash table."""
-return max(maxmem_kb / 64, shadow_mem_kb)
-
class HVMImageHandler(ImageHandler):
@@ -588,7 +586,7 @@ class X86_Linux_ImageHandler(LinuxImageH
_handlers = {
"powerpc": {
-"linux": LinuxImageHandler,
+"linux": PPC_LinuxImageHandler,
"prose": PPC_ProseImageHandler,
},
"ia64": {
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 2/3] linux: build start_info_t from devtree
* Ryan Harper <[EMAIL PROTECTED]> [2007-01-24 11:51]:
> This patch adds support to linux:xen_init_early() to create a
> start_info_t structure from properties in /xen/start_info_t if the
> device tree does not have a pointer (/xen/start-info) to a previously
> constructed start_info_t in memory.
Updated to create start_info_t from /xen/console and /xen/store devtree
values if /xen/start-info isn't present.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
setup.c | 28 +++-
1 files changed, 27 insertions(+), 1 deletion(-)
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
---
diff -r ab3b5849331d arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.cSun Jan 21 08:36:53 2007 -0500
+++ b/arch/powerpc/platforms/xen/setup.cThu Jan 25 10:59:53 2007 -0600
@@ -32,6 +32,7 @@ EXPORT_SYMBOL(HYPERVISOR_shared_info);
EXPORT_SYMBOL(HYPERVISOR_shared_info);
/* Raw start-of-day parameters from the hypervisor. */
+start_info_t xsi;
start_info_t *xen_start_info;
extern struct machdep_calls mach_maple_md;
@@ -94,7 +95,32 @@ static void __init xen_init_early(void)
xen = of_find_node_by_path("/xen");
si = (u64 *)get_property(xen, "start-info", NULL);
- xen_start_info = (start_info_t *)__va(*si);
+
+ /* build our own start_info_t if prop start-info not found */
+ if (si != NULL ) {
+ xen_start_info = (start_info_t *)__va(*si);
+ } else {
+ struct device_node *console;
+ struct device_node *store;
+
+ console = of_find_node_by_path("/xen/console");
+ store = of_find_node_by_path("/xen/store");
+
+ xen_start_info = &xsi;
+
+ /* fill out start_info_t from devtree */
+ xen_start_info->shared_info = *((u64 *)get_property(xen,
+ "shared-info", NULL));
+ xen_start_info->store_mfn = *((u64 *)get_property(store,
+ "reg", NULL));
+ xen_start_info->store_evtchn = *((u32 *)get_property(store,
+ "interrupts", NULL));
+ xen_start_info->console.domU.mfn = *((u64
*)get_property(console,
+ "reg", NULL));
+ xen_start_info->console.domU.evtchn = *((u32
*)get_property(console,
+ "interrupts", NULL));
+ }
+
HYPERVISOR_shared_info = __va(xen_start_info->shared_info);
udbg_init_xen();
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 1/3] libxc: add start_info_t node to devtree
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-24 12:42]:
> The data that was in start_info_t should be just simple bindings in "/
> xen" since they describe xen, there is no need to create a new node.
> many of the props are not needed since they are expressed elsewhere
> in the devtree or perhaps differently.
> more below.
New rev:
-dropped /xen/start_info_t, hanging new node /xen/store
-fixed up /xen/console/reg to be proper value
-fixed up /xen/console/interrupts to use value passed from xend
-renamed property 'shared_info' to 'shared-info'
-fixed 'shared-info' to be a proper value
-reduced the number of pages reserved at the end of RMA from 4 to 3
as we no longer need to reserve a page for start_info_t
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
mk_flatdevtree.c | 45 +++--
mk_flatdevtree.h |6 ++-
xc_linux_build.c | 83 ++-
3 files changed, 80 insertions(+), 54 deletions(-)
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
---
diff -r ed5ee9dde0bd tools/libxc/powerpc64/mk_flatdevtree.c
--- a/tools/libxc/powerpc64/mk_flatdevtree.cSun Jan 21 08:17:46 2007 -0500
+++ b/tools/libxc/powerpc64/mk_flatdevtree.cThu 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)
{
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;
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;
uint32_t cpu0_phandle = get_phandle();
uint32_t xen_phandle = get_phandle();
uint32_t rma_phandle = get_phandle();
@@ -419,11 +425,6 @@ int make_devtree(struct ft_cxt *root,
/* xen = root.addnode('xen') */
ft_begin_node(root, "xen");
-/* start-info is the first page in the RMA reserved area */
-val[0] = cpu_to_be64((u64) (rma_bytes - rma_reserve));
-val[1] = cpu_to_be64((u64) PAGE_SIZE);
-ft_prop(root, "start-info", val, sizeof(val));
-
/* xen.addprop('version', 'Xen-3.0-unstable\0') */
ft_prop_str(root, "version", "Xen-3.0-unstable");
@@ -432,6 +433,11 @@ int make_devtree(struct ft_cxt *root,
val[1] = cpu_to_be64((u64) 0);
ft_prop(root, "reg", val, sizeof(val));
+/* point to shared_info_t page base addr */
+val[0] = cpu_to_be64((u64) shared_info_addr);
+val[1] = cpu_to_be64((u64) PAGE_SIZE);
+ft_prop(root, "shared-info", val, sizeof(val));
+
/* xen.addprop('domain-name', imghandler.vm.getName() + '\0') */
/* libxc doesn't know the domain name, that is purely a xend thing */
/* ft_prop_str(root, "domain-name", domain_name); */
@@ -442,12 +448,33 @@ int make_devtree(struct ft_cxt *root,
/* xencons = xen.addnode('console') */
ft_begin_node(root, "console");
-/* xencons.addprop('interrupts', 1, 0) */
-val32[0] = cpu_to_be32((u32) 1);
+/* console_mfn */
+val[0] = cpu_to_be64((u64) console_mfn);
+val[1] = cpu_to_be64((u64) PAGE_SIZE);
+ft_prop(root, "reg", val, sizeof(val));
+
+/* xencons.addprop('interrupts', console_evtchn, 0) */
+val32[0] = cpu_to_be32((u32) console_evtchn);
val32[1] = cpu_to_be32((u32) 0);
ft_prop(root, "interrupts", val32, sizeof(val32));
/* end of console */
+ft_end_node(root);
+
+/* start store node */
+ft_begin_node(root, "store");
+
+/* store_mfn */
+val[0] = cpu_to_be64((u64) store_mfn);
+val[1] = cpu_to_be64((u64) PAGE_SIZE);
+ft_prop(root, "reg", val, sizeof(val));
+
+/* store event channel */
+val32[0] = cpu_to_be32((u32) store_evtchn);
+val32[1] = cpu_to_be32((u32) 0);
+ft_prop(root, "interrupts", val32, sizeof(val32));
+
+/* end of store */
ft_end_node(root);
/* end of xen node */
diff -r ed5ee9dde0bd tools/libxc/powerpc64/mk_flatdevtree.h
--- a/tools/libxc/powerpc64/mk_flatdevtree.hSun Jan 21 08:17:46 2007 -0500
+++ b/tools/libxc/powerpc64/mk_flatdevtree.hThu Jan 25 11:27:58 2007 -0600
@@ -32,8 +32,10 @@ extern int make_devtree(struct ft_cxt *r
unsigned lo
Re: [XenPPC] [PATCH 3/3] sync xen/include/public/xen.h with unstable
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-24 12:52]: > since we don;t use the sparse tree, we'll need a linux patch with > this change as well. I looks to me that linux-ppc-2.6.hg/include/xen/interface/xen.h is already in sync w.r.t start_info_t so no extra patch for linux needed. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
