[XenPPC] [PATCH] Enable more IP options to default kernel config
This patch enables many IP options to allow support for better support of IP tables & IPv6. This patch mainly address an issue with SuSE firewall scripts that will hang on startup. This bug can be found here: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=841 Signed-off-by: Jerone Young <[EMAIL PROTECTED]> # HG changeset patch # User [EMAIL PROTECTED] # Date 1168927970 21600 # Node ID d450e2b2a85a7640643ecf7b2fddff2faa6dbcd4 # Parent bbf2db4ddf5400e908ee6bf92ac798e5cfed82a0 Add many options for IP configuration so that Suse firewall scripts will no longer fail. diff -r bbf2db4ddf54 -r d450e2b2a85a arch/powerpc/configs/xen_maple_defconfig --- a/arch/powerpc/configs/xen_maple_defconfig Tue Dec 19 09:22:37 2006 -0500 +++ b/arch/powerpc/configs/xen_maple_defconfig Tue Jan 16 00:12:50 2007 -0600 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.17 -# Thu Oct 12 16:16:49 2006 +# Mon Jan 15 23:48:47 2007 # CONFIG_PPC64=y CONFIG_64BIT=y @@ -230,15 +230,24 @@ CONFIG_XFRM=y # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y -# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_ASK_IP_FIB_HASH=y +# CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_FWMARK=y +CONFIG_IP_ROUTE_MULTIPATH=y +# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set +# CONFIG_IP_ROUTE_VERBOSE is not set CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=y # CONFIG_NET_IPGRE is not set -# CONFIG_IP_MROUTE is not set +CONFIG_IP_MROUTE=y +CONFIG_IP_PIMSM_V1=y +CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set @@ -257,9 +266,18 @@ CONFIG_TCP_CONG_BIC=y # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set -# CONFIG_IPV6 is not set -# CONFIG_INET6_XFRM_TUNNEL is not set -# CONFIG_INET6_TUNNEL is not set +CONFIG_IPV6=y +CONFIG_IPV6_PRIVACY=y +CONFIG_IPV6_ROUTER_PREF=y +CONFIG_IPV6_ROUTE_INFO=y +CONFIG_INET6_AH=y +CONFIG_INET6_ESP=y +CONFIG_INET6_IPCOMP=y +CONFIG_INET6_XFRM_TUNNEL=y +CONFIG_INET6_TUNNEL=y +CONFIG_INET6_XFRM_MODE_TRANSPORT=y +CONFIG_INET6_XFRM_MODE_TUNNEL=y +CONFIG_IPV6_TUNNEL=y # CONFIG_NETWORK_SECMARK is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set @@ -268,15 +286,114 @@ CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # -# CONFIG_NETFILTER_NETLINK is not set -# CONFIG_NF_CONNTRACK is not set -# CONFIG_NETFILTER_XTABLES is not set +CONFIG_NETFILTER_NETLINK=y +CONFIG_NETFILTER_NETLINK_QUEUE=y +CONFIG_NETFILTER_NETLINK_LOG=y +CONFIG_NETFILTER_XTABLES=y +CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y +CONFIG_NETFILTER_XT_TARGET_CONNMARK=y +CONFIG_NETFILTER_XT_TARGET_MARK=y +CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y +CONFIG_NETFILTER_XT_TARGET_NOTRACK=y +CONFIG_NETFILTER_XT_MATCH_COMMENT=y +CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y +CONFIG_NETFILTER_XT_MATCH_CONNMARK=y +CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y +CONFIG_NETFILTER_XT_MATCH_DCCP=y +CONFIG_NETFILTER_XT_MATCH_ESP=y +CONFIG_NETFILTER_XT_MATCH_HELPER=y +CONFIG_NETFILTER_XT_MATCH_LENGTH=y +CONFIG_NETFILTER_XT_MATCH_LIMIT=y +CONFIG_NETFILTER_XT_MATCH_MAC=y +CONFIG_NETFILTER_XT_MATCH_MARK=y +CONFIG_NETFILTER_XT_MATCH_POLICY=y +CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y +CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y +CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y +CONFIG_NETFILTER_XT_MATCH_QUOTA=y +CONFIG_NETFILTER_XT_MATCH_REALM=y +CONFIG_NETFILTER_XT_MATCH_SCTP=y +CONFIG_NETFILTER_XT_MATCH_STATE=y +CONFIG_NETFILTER_XT_MATCH_STATISTIC=y +CONFIG_NETFILTER_XT_MATCH_STRING=y +CONFIG_NETFILTER_XT_MATCH_TCPMSS=y # # IP: Netfilter Configuration # -# CONFIG_IP_NF_CONNTRACK is not set +CONFIG_IP_NF_CONNTRACK=y +CONFIG_IP_NF_CT_ACCT=y +CONFIG_IP_NF_CONNTRACK_MARK=y +CONFIG_IP_NF_CONNTRACK_EVENTS=y +CONFIG_IP_NF_CONNTRACK_NETLINK=y +CONFIG_IP_NF_CT_PROTO_SCTP=y +CONFIG_IP_NF_FTP=y +CONFIG_IP_NF_IRC=y +# CONFIG_IP_NF_NETBIOS_NS is not set +CONFIG_IP_NF_TFTP=y +CONFIG_IP_NF_AMANDA=y +CONFIG_IP_NF_PPTP=y +# CONFIG_IP_NF_H323 is not set +# CONFIG_IP_NF_SIP is not set # CONFIG_IP_NF_QUEUE is not set +CONFIG_IP_NF_IPTABLES=y +CONFIG_IP_NF_MATCH_IPRANGE=y +CONFIG_IP_NF_MATCH_TOS=y +CONFIG_IP_NF_MATCH_RECENT=y +CONFIG_IP_NF_MATCH_ECN=y +CONFIG_IP_NF_MATCH_DSCP=y +CONFIG_IP_NF_MATCH_AH=y +CONFIG_IP_NF_MATCH_TTL=y +CONFIG_IP_NF_MATCH_OWNER=y +CONFIG_IP_NF_MATCH_ADDRTYPE=y +CONFIG_IP_NF_MATCH_HASHLIMIT=y +CONFIG_IP_NF_FILTER=y +CONFIG_IP_NF_TARGET_REJECT=y +CONFIG_IP_NF_TARGET_LOG=y +CONFIG_IP_NF_TARGET_ULOG=y +CONFIG_IP_NF_TARGET_TCPMSS=y +CONFIG_IP_NF_NAT=y +CONFIG_IP_NF_NAT_NEEDED=y +CONFIG_IP_NF_TARGET_MASQUERADE=y +CONFIG_IP_NF_TARGET_REDIRECT=y +CONFIG_IP_NF_TARGET_NETMAP=y +CONFIG_IP_NF_TARGET_SAME=y +CONFIG_IP_NF_NAT_SNMP_BASIC=y +CONFIG_IP_NF_NAT_IRC=y +CONFIG_IP_NF_NAT_FTP=y +CONFIG_IP_NF_NAT_TFTP=y +CONFIG_IP_NF_NAT_AMANDA=y +CONFIG_IP_NF_NAT_PPTP=y +CONFIG_IP_NF_MANGLE=y +CONFIG_IP_NF_TARGET_TOS=y +CONFIG_IP_NF_TARGET_ECN=y +CONFIG_IP_NF_TARGET_D
Re: [XenPPC] [PATCH 3 of 4] [PATCH] Move flat device tree construction from python to libxc for xc_linux_build()
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(0x100, 0x1000) */ > > +val[0] = cpu_to_be64((u64) 0x100); > > +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. -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 3 of 4] [PATCH] Move flat device tree construction from python to libxc for xc_linux_build()
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(0x100, 0x1000) */ +val[0] = cpu_to_be64((u64) 0x100); +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? -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] [POWERPC][XEN] Mark heap memory based on boot_of.c's allocator
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Date 1168914221 21600
# Node ID dc8551babde44184e72cada0416b9c1f19ed1ada
# Parent dbc74db14a4b39d359365fcf8257216d968fa269
[POWERPC][XEN] Mark heap memory based on boot_of.c's allocator.
- Explain why we have another allocator (that wasn't so hard now was it?).
- Create and export boot_of_mem_avail() to allow later code to iterate over the
allocator bitmap.
- Use boot_of_mem_avail() to place memory in the heap, instead of using globals
and making assumptions about the ordering of reserved areas.
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
diff -r dbc74db14a4b -r dc8551babde4 xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Dec 12 14:35:07 2006 -0600
+++ b/xen/arch/powerpc/boot_of.cMon Jan 15 20:23:41 2007 -0600
@@ -13,7 +13,7 @@
* along with this program; if not, write to the Free Software
* Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
- * Copyright (C) IBM Corp. 2005, 2006
+ * Copyright IBM Corp. 2005, 2006, 2007
*
* Authors: Jimi Xenidis <[EMAIL PROTECTED]>
* Hollis Blanchard <[EMAIL PROTECTED]>
@@ -43,6 +43,14 @@ static int of_out;
static int of_out;
static ulong eomem;
+/* Track memory during early boot with a limited per-page bitmap. We need an
+ * allocator to tell us where we can place RTAS, our copy of the device tree.
+ * We could examine the "available" properties in memory nodes, but we
+ * apparently can't depend on firmware to update those when we call "claim". So
+ * we need to track it ourselves.
+ * We can't dynamically allocate the bitmap, because we would need something
+ * to tell us where it's safe to allocate...
+ */
#define MEM_AVAILABLE_PAGES ((32 << 20) >> PAGE_SHIFT)
static DECLARE_BITMAP(mem_available_pages, MEM_AVAILABLE_PAGES);
@@ -530,6 +538,37 @@ static ulong boot_of_alloc(ulong size)
pos = pos + i;
}
+}
+
+int boot_of_mem_avail(int pos, ulong *startpage, ulong *endpage)
+{
+ulong freebit;
+ulong usedbit;
+
+if (pos >= MEM_AVAILABLE_PAGES)
+/* Stop iterating. */
+return -1;
+
+/* Find first free page. */
+freebit = find_next_zero_bit(mem_available_pages, MEM_AVAILABLE_PAGES,
pos);
+if (freebit >= MEM_AVAILABLE_PAGES) {
+/* We know everything after MEM_AVAILABLE_PAGES is still free. */
+*startpage = MEM_AVAILABLE_PAGES << PAGE_SHIFT;
+*endpage = ~0UL;
+return freebit;
+}
+*startpage = freebit << PAGE_SHIFT;
+
+/* Now find first used page after that. */
+usedbit = find_next_bit(mem_available_pages, MEM_AVAILABLE_PAGES, freebit);
+if (usedbit >= MEM_AVAILABLE_PAGES) {
+/* We know everything after MEM_AVAILABLE_PAGES is still free. */
+*endpage = ~0UL;
+return usedbit;
+}
+
+*endpage = usedbit << PAGE_SHIFT;
+return usedbit;
}
static ulong boot_of_mem_init(void)
diff -r dbc74db14a4b -r dc8551babde4 xen/arch/powerpc/memory.c
--- a/xen/arch/powerpc/memory.c Tue Dec 12 14:35:07 2006 -0600
+++ b/xen/arch/powerpc/memory.c Mon Jan 15 20:23:41 2007 -0600
@@ -13,7 +13,7 @@
* along with this program; if not, write to the Free Software
* Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
- * Copyright (C) IBM Corp. 2006
+ * Copyright IBM Corp. 2006, 2007
*
* Authors: Dan Poff <[EMAIL PROTECTED]>
* Jimi Xenidis <[EMAIL PROTECTED]>
@@ -25,7 +25,7 @@
#include "oftree.h"
#include "rtas.h"
-#undef DEBUG
+#define DEBUG
#ifdef DEBUG
#define DBG(fmt...) printk(fmt)
#else
@@ -42,8 +42,6 @@ unsigned long xenheap_phys_end;
unsigned long xenheap_phys_end;
static uint nr_pages;
static ulong xenheap_size;
-static ulong save_start;
-static ulong save_end;
struct membuf {
ulong start;
@@ -51,30 +49,6 @@ struct membuf {
};
typedef void (*walk_mem_fn)(struct membuf *, uint);
-
-static ulong free_xenheap(ulong start, ulong end)
-{
-start = ALIGN_UP(start, PAGE_SIZE);
-end = ALIGN_DOWN(end, PAGE_SIZE);
-
-DBG("%s: 0x%lx - 0x%lx\n", __func__, start, end);
-
-/* need to do this better */
-if (save_start <= end && save_start >= start) {
-DBG("%s: Go around the saved area: 0x%lx - 0x%lx\n",
- __func__, save_start, save_end);
-init_xenheap_pages(start, ALIGN_DOWN(save_start, PAGE_SIZE));
-xenheap_size += ALIGN_DOWN(save_start, PAGE_SIZE) - start;
-
-init_xenheap_pages(ALIGN_UP(save_end, PAGE_SIZE), end);
-xenheap_size += end - ALIGN_UP(save_end, PAGE_SIZE);
-} else {
-init_xenheap_pages(start, end);
-xenheap_size += end - start;
-}
-
-return ALIGN_UP(end, PAGE_SIZE);
-}
static void set_max_page(struct membuf *mb, uint entries)
{
@@ -113,6 +87,7 @@ static void heap_init(struct membuf *mb,
start_blk = xenheap_phys_end;
}
+DBG("boot free: %016lx - %016lx\n", start_blk, end_blk);
init_boot
Re: [XenPPC] [PATCH] [POWERPC][XEN] Mark heap memory based on boot_of.c's allocator
On Mon, 2007-01-15 at 18:01 -0500, Jimi Xenidis wrote:
> > @@ -530,6 +538,33 @@ static ulong boot_of_alloc(ulong size)
> >
> > pos = pos + i;
> > }
> > +}
> > +
> > +int boot_of_mem_avail(int pos, ulong *startpage, ulong *endpage)
> If you'd like to hide the bitmap, then perhaps the first arg should
> be a start address and return the address of the next "used" page?
That's an idea. However, I was thinking something more along the lines
of an opaque iterator token.
> > +{
> > +ulong freebit;
> > +ulong usedbit;
> > +
> > +/* find first free page. */
> > +freebit = find_next_zero_bit(mem_available_pages,
> > MEM_AVAILABLE_PAGES, pos);
> > +if (freebit >= MEM_AVAILABLE_PAGES) {
> > +/* We know everything after MEM_AVAILABLE_PAGES is still
> > free. */
> > +*startpage = MEM_AVAILABLE_PAGES << PAGE_SHIFT;
> > +*endpage = ~0UL;
> > +return -1;
> > +}
> > +*startpage = freebit << PAGE_SHIFT;
> > +
> > +/* now find first used page after that. */
> > +usedbit = find_next_bit(mem_available_pages,
> > MEM_AVAILABLE_PAGES, freebit);
> > +if (usedbit >= MEM_AVAILABLE_PAGES) {
> > +/* We know everything after MEM_AVAILABLE_PAGES is still
> > free. */
> > +*endpage = ~0UL;
> > +return -1;
> > +}
> > +*endpage = usedbit << PAGE_SHIFT;
>
> I'm not 100% but the code below looks like require that end represent
> a free page so "usedbit - 1"?
It's actually the address of the end of the free memory. For example, if
you have a single page available, let's say at 0x4000, start would be
0x4000 and end would be 0x5000. The length is end - start, or 0x1000.
> > @@ -214,16 +148,22 @@ void memory_init(module_t *mod, int mcou
> >
> > printk("End of RAM: %luMiB (%luKiB)\n", eomem >> 20, eomem >>
> > 10);
> >
> > -/* Architecturally the first 4 pages are exception hendlers, we
> > - * will also be copying down some code there */
> > +/* Architecturally the first 4 pages are exception handlers. */
> > heap_start = 4 << PAGE_SHIFT;
> > -if (oftree < (ulong)_start)
> > -heap_start = ALIGN_UP(oftree_end, PAGE_SIZE);
> > -
>
> all the images below are in the bitmap, so can;t you use
> boot_of_mem_avail() to figure this out?
Yes, and that makes me very happy. :) Revised patch follows.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 3 of 4] [PATCH] Move flat device tree construction from python to libxc for xc_linux_build()
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(0x100, 0x1000) */ > >>> +val[0] = cpu_to_be64((u64) 0x100); > >>> +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 . -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] [POWERPC][XEN] Mark heap memory based on boot_of.c's allocator
Please double-check the usedbit issue below otherwise I'll ACK this.
-JX
On Jan 11, 2007, at 4:51 PM, Hollis Blanchard wrote:
# HG changeset patch
# User Hollis Blanchard <[EMAIL PROTECTED]>
# Date 1168550320 21600
# Node ID d98b2fbc100cfec5678a787ba7bfd0b065254793
# Parent dbc74db14a4b39d359365fcf8257216d968fa269
[POWERPC][XEN] Mark heap memory based on boot_of.c's allocator.
- Explain why we have another allocator (that wasn't so hard now
was it?).
- Create and export boot_of_mem_avail() to allow later code to
iterate over the
allocator bitmap.
- Use boot_of_mem_avail() to place memory in the heap, instead of
using globals
and making assumptions about the ordering of reserved areas.
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
diff -r dbc74db14a4b -r d98b2fbc100c xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Dec 12 14:35:07 2006 -0600
+++ b/xen/arch/powerpc/boot_of.cThu Jan 11 15:18:40 2007 -0600
@@ -43,6 +43,14 @@ static int of_out;
static int of_out;
static ulong eomem;
+/* Track memory during early boot with a limited per-page bitmap.
We need an
+ * allocator to tell us where we can place RTAS, our copy of the
device tree.
+ * We could examine the "available" properties in memory nodes,
but we
+ * apparently can't depend on firmware to update those when we
call "claim". So
+ * we need to track it ourselves.
+ * We can't dynamically allocate the bitmap, because we would need
something
+ * to tell us where it's safe to allocate...
+ */
#define MEM_AVAILABLE_PAGES ((32 << 20) >> PAGE_SHIFT)
static DECLARE_BITMAP(mem_available_pages, MEM_AVAILABLE_PAGES);
@@ -530,6 +538,33 @@ static ulong boot_of_alloc(ulong size)
pos = pos + i;
}
+}
+
+int boot_of_mem_avail(int pos, ulong *startpage, ulong *endpage)
If you'd like to hide the bitmap, then perhaps the first arg should
be a start address and return the address of the next "used" page?
+{
+ulong freebit;
+ulong usedbit;
+
+/* find first free page. */
+freebit = find_next_zero_bit(mem_available_pages,
MEM_AVAILABLE_PAGES, pos);
+if (freebit >= MEM_AVAILABLE_PAGES) {
+/* We know everything after MEM_AVAILABLE_PAGES is still
free. */
+*startpage = MEM_AVAILABLE_PAGES << PAGE_SHIFT;
+*endpage = ~0UL;
+return -1;
+}
+*startpage = freebit << PAGE_SHIFT;
+
+/* now find first used page after that. */
+usedbit = find_next_bit(mem_available_pages,
MEM_AVAILABLE_PAGES, freebit);
+if (usedbit >= MEM_AVAILABLE_PAGES) {
+/* We know everything after MEM_AVAILABLE_PAGES is still
free. */
+*endpage = ~0UL;
+return -1;
+}
+*endpage = usedbit << PAGE_SHIFT;
I'm not 100% but the code below looks like require that end represent
a free page so "usedbit - 1"?
+
+return usedbit;
}
static ulong boot_of_mem_init(void)
diff -r dbc74db14a4b -r d98b2fbc100c xen/arch/powerpc/memory.c
--- a/xen/arch/powerpc/memory.c Tue Dec 12 14:35:07 2006 -0600
+++ b/xen/arch/powerpc/memory.c Thu Jan 11 15:18:40 2007 -0600
@@ -42,8 +42,6 @@ unsigned long xenheap_phys_end;
unsigned long xenheap_phys_end;
static uint nr_pages;
static ulong xenheap_size;
-static ulong save_start;
-static ulong save_end;
struct membuf {
ulong start;
@@ -51,30 +49,6 @@ struct membuf {
};
typedef void (*walk_mem_fn)(struct membuf *, uint);
-
-static ulong free_xenheap(ulong start, ulong end)
-{
-start = ALIGN_UP(start, PAGE_SIZE);
-end = ALIGN_DOWN(end, PAGE_SIZE);
-
-DBG("%s: 0x%lx - 0x%lx\n", __func__, start, end);
-
-/* need to do this better */
-if (save_start <= end && save_start >= start) {
-DBG("%s: Go around the saved area: 0x%lx - 0x%lx\n",
- __func__, save_start, save_end);
-init_xenheap_pages(start, ALIGN_DOWN(save_start, PAGE_SIZE));
-xenheap_size += ALIGN_DOWN(save_start, PAGE_SIZE) - start;
-
-init_xenheap_pages(ALIGN_UP(save_end, PAGE_SIZE), end);
-xenheap_size += end - ALIGN_UP(save_end, PAGE_SIZE);
-} else {
-init_xenheap_pages(start, end);
-xenheap_size += end - start;
-}
-
-return ALIGN_UP(end, PAGE_SIZE);
-}
static void set_max_page(struct membuf *mb, uint entries)
{
@@ -113,6 +87,7 @@ static void heap_init(struct membuf *mb,
start_blk = xenheap_phys_end;
}
+DBG("boot free: %016lx - %016lx\n", start_blk, end_blk);
init_boot_pages(start_blk, end_blk);
total_pages += (end_blk - start_blk) >> PAGE_SHIFT;
}
@@ -141,72 +116,31 @@ static void ofd_walk_mem(void *m, walk_m
}
}
-static void setup_xenheap(module_t *mod, int mcount)
-{
-int i;
-ulong freemem;
-
-freemem = ALIGN_UP((ulong)_end, PAGE_SIZE);
-
-for (i = 0; i < mcount; i++) {
-u32 s;
-
-if (mod[i].mod_end == mod[i].mod_start)
-continue;
-
-s = ALIGN_DOWN(mod[i].mod_start, PAGE_SIZE);
-
-if (mo
Re: [XenPPC] [PATCH 3 of 4] [PATCH] Move flat device tree construction from python to libxc for xc_linux_build()
On Jan 15, 2007, at 4:13 PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-15 14:53]:
On Jan 15, 2007, at 1:51 PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-11 16:53]:
[snip]
- renamed find_first_cpu to find_cpu, we don't care which cpu we
find
I believe you _must_ use the the entry that has a reg property of 0.
Is that because the properties we are interested aren't guaranteed
to be
present in all cpu nodes?
Well I would like it to have a reg=0 and cpu#=0
Some OF devtrees contain nodes that described shares resources (like
L3, L4 caches), usually the full definition is in the lowest number
of the sharers and the secondaries can simply us a property that
contains the phandle of the original node.
[snip]
SEGVs are good! :)
WFM. =)
No.. seriously!
[snip]
+static int copynode(struct ft_cxt *cxt, const char *dirpath, const
char **propfilter)
+{
This is totally informational, but I think the blob/fnmatch routines
may make this code way simpler.
sure and I liked my regexp, but the concern was what sort of libc
functions would be available in Xen when we implement copynode down
there for dom0 devtree construction.
this is a good point, however dom0 will copy everything.
[snip]
+int make_devtree(
[snip]
Any ideas what this reservation is for? is it for the flat-devtree
itself?
Nope.
+/* root.reserve(0x100, 0x1000) */
+val[0] = cpu_to_be64((u64) 0x100);
+val[1] = cpu_to_be64((u64) 0x1000);
+ft_add_rsvmap(root, val[0], val[1]);
Hollis?!
+
this value is keyed off of rma_bytes
No idea, just duping reservations that the python code made. Is there
some place I should be getting these values from?
Sure.. you calculate rma_bytes below when you fill in the /[EMAIL PROTECTED]
stuff in.
that is what you are missing below.
[snip]
+/* xen = root.addnode('xen') */
+ft_begin_node(root, "xen");
the 0x3ffc00 value is offset from rma_bytes
+
+/* xen.addprop('start-info', long(0x3ffc000), long(0x1000)) */
+val[0] = cpu_to_be64((u64) 0x3ffc000);
+val[1] = cpu_to_be64((u64) 0x1000);
+ft_prop(root, "start-info", val, sizeof(val));
What am I missing here?
+
+/* [EMAIL PROTECTED] is all the rest */
+if (remaining > 0)
+{
this really should be "memory@"
+/* mem = root.addnode('[EMAIL PROTECTED]') */
+ft_begin_node(root, "[EMAIL PROTECTED]");
+
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 3 of 4] [PATCH] Move flat device tree construction from python to libxc for xc_linux_build()
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-15 14:53]:
>
> On Jan 15, 2007, at 1:51 PM, Ryan Harper wrote:
>
> >* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-11 16:53]:
> >>
> >>Ok there are a few things here.
> >
> BTW: some of these issues existed in the original python, but they
> are yours now :)
Of course =)
>
> >Respun with fixes:
> >
> >- preserve and return errno where approriate
> >- using open/close and read/write instead of f*
> >- dropped vcpu argument, only fill out one cpu in devtree
> >- dropped regexp requirment, use a null-terminated list of filters
> >- made sure to call closedir()
> >- fixed double-free of bph on error path
> >- fixed static function names
> >- renamed find_first_cpu to find_cpu, we don't care which cpu we find
>
> I believe you _must_ use the the entry that has a reg property of 0.
Is that because the properties we are interested aren't guaranteed to be
present in all cpu nodes?
> >+static int readfile(const char *fullpath, void *data, int len)
> >+{
> >+struct stat st;
> >+int saved_errno;
> >+int rc = -1;
> >+int fd;
> >+
> >+if ((fd = open(fullpath, O_RDONLY)) == -1) {
> >+PERROR("%s: failed to open file %s", __func__, fullpath);
> >+return -1;
> >+}
> >+
> >+if ((rc = fstat(fd, &st)) == -1) {
> >+PERROR("%s: failed to stat fd %d", __func__, fd);
> >+goto error;
> >+}
> >+
> >+if (S_ISREG(st.st_mode))
> >+rc = read(fd, data, MIN(len, st.st_size));
> My brain fart, the MIN() is not necessary. you want to read no-more
> than your buffer allows, so just use len and forget about
> st.st_size. This assumes that you are not interested in the case
> where len yields a partial read, are you?
OK. I thought about putting a warning that the payload is larger than
the length of the buffer and truncating.
> >+ *
> >+ * compare @property string to each string in @filter
> >+ *
> >+ * return 1 if @property matches any filter, otherwise 0
> >+ *
> >+ */
> >+static int match(const char *property, const char **filter)
> >+{
> >+int i;
> >+
> >+if ((property == NULL) || (filter == NULL) || (*filter == NULL))
> >+return -1;
> This will get interpreted as a "match" bye its users, I would not
> even bother checking.
It shouldn't since match == 1. But I see what you mean as I used
if ( !match())
> SEGVs are good! :)
WFM. =)
> >+
> >+for (i=0; filter[i] != NULL; i++) {
> >+/* compare the filter to property, ignoring NULL
> >terminator */
> >+if (strncmp(property, filter[i], sizeof(filter[i])-1) == 0)
>
> This function has no clue what the contents of "filter" is so you
> cannot use sizeof().
> Assuming sizeof() worked, it is your intention to match the substring?
Ack! I was thinking strlen() since we are comparing the property to the
full-lenght of the filter string. The -1 is probably my screw up for
using sizeof() instead of strlen().
> >+static int copynode(struct ft_cxt *cxt, const char *dirpath, const
> >char **propfilter)
> >+{
>
> This is totally informational, but I think the blob/fnmatch routines
> may make this code way simpler.
sure and I liked my regexp, but the concern was what sort of libc
functions would be available in Xen when we implement copynode down
there for dom0 devtree construction.
>
> >+struct dirent *tree;
> >+struct stat st;
> >+DIR *dir;
> >+char fullpath[MAX_PATH];
> >+char *bname = NULL;
> >+char *basec = NULL;
> >+int saved_errno;
> >+
> >+if ((dir = opendir(dirpath)) == NULL) {
> >+PERROR("%s: failed to open dir %s", __func__, dirpath);
> >+return -1;
> >+}
> >+
> >+while (1) {
> >+if ((tree = readdir(dir)) == NULL)
> >+break; /* reached end of directory entries */
> >+
> >+/* ignore . and .. */
> >+if (strcmp(tree->d_name,"." ) == 0 || strcmp(tree-
> >>d_name,"..") == 0)
> >+continue;
> >+
> >+/* build full path name of the file, for stat() */
> >+if (snprintf(fullpath, sizeof(fullpath), "%s/%s", dirpath,
> >tree->d_name) <= 0) {
> snprintf will almost never return -1, what you are really interested
> in is if the result does not fit in the buffer, so the test would be:
> >= sizeof(fullpath).
> To "be complete" you should also check against "!=-1" which means
> that the strlen() of the result would be to bit for an int (hard to
> do that, but possible) :)
OK
> >+int make_devtree(
> >+struct ft_cxt *root,
> >+uint32_t domid, uint32_t mem_mb,
> >+unsigned long shadow_mb,
> >+const char *bootargs)
> >+{
> >+struct boot_param_header *bph = NULL;
> >+uint64_t val[2];
> >+uint32_t val32[2];
> >+uint64_t totalmem;
> >+uint64_t rma_bytes;
> >+uint64_t remaining;
> >+uint64_t pft_size;
> >+int64_t shadow_mb_log;
> >+char cpupath[MAX_PATH];
> >+const char *propfilter[] = { "ibm", "linux,", NULL };
> >+char *cpupath_copy = NULL;
> >+char *cpuname =
Re: [XenPPC] [PATCH 3 of 4] [PATCH] Move flat device tree construction from python to libxc for xc_linux_build()
On Jan 15, 2007, at 1:51 PM, Ryan Harper wrote:
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-11 16:53]:
Ok there are a few things here.
BTW: some of these issues existed in the original python, but they
are yours now :)
Respun with fixes:
- preserve and return errno where approriate
- using open/close and read/write instead of f*
- dropped vcpu argument, only fill out one cpu in devtree
- dropped regexp requirment, use a null-terminated list of filters
- made sure to call closedir()
- fixed double-free of bph on error path
- fixed static function names
- renamed find_first_cpu to find_cpu, we don't care which cpu we find
I believe you _must_ use the the entry that has a reg property of 0.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
b/tools/libxc/powerpc64/mk_flatdevtree.c | 567 +++
b/tools/libxc/powerpc64/mk_flatdevtree.h | 44 ++
tools/libxc/powerpc64/Makefile |1
tools/libxc/powerpc64/xc_linux_build.c | 30 +
tools/libxc/xenguest.h |4
tools/python/xen/lowlevel/xc/xc.c| 12
tools/python/xen/xend/image.py |5
7 files changed, 646 insertions(+), 17 deletions(-)
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
---
[PATCH] Move flat device tree construction from python to libxc for
xc_linux_build().
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
diff -r 3edbfb956864 tools/libxc/powerpc64/Makefile
--- a/tools/libxc/powerpc64/MakefileFri Jan 12 15:16:42 2007 -0600
+++ b/tools/libxc/powerpc64/MakefileFri Jan 12 15:16:42 2007 -0600
@@ -1,4 +1,5 @@ GUEST_SRCS-y += powerpc64/flatdevtree.c
GUEST_SRCS-y += powerpc64/flatdevtree.c
+GUEST_SRCS-y += powerpc64/mk_flatdevtree.c
GUEST_SRCS-y += powerpc64/xc_linux_build.c
GUEST_SRCS-y += powerpc64/xc_prose_build.c
GUEST_SRCS-y += powerpc64/utils.c
diff -r 3edbfb956864 tools/libxc/powerpc64/xc_linux_build.c
--- a/tools/libxc/powerpc64/xc_linux_build.c Fri Jan 12 15:16:42
2007 -0600
+++ b/tools/libxc/powerpc64/xc_linux_build.c Fri Jan 12 16:00:33
2007 -0600
@@ -13,9 +13,10 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.
*
- * Copyright (C) IBM Corporation 2006
+ * Copyright IBM Corporation 2006, 2007
*
* Authors: Hollis Blanchard <[EMAIL PROTECTED]>
+ * Ryan Harper <[EMAIL PROTECTED]>
*/
#include
@@ -36,6 +37,7 @@
#include "flatdevtree_env.h"
#include "flatdevtree.h"
#include "utils.h"
+#include "mk_flatdevtree.h"
#define INITRD_ADDR (24UL << 20)
#define DEVTREE_ADDR (16UL << 20)
@@ -238,8 +240,7 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn,
- void *devtree)
+ unsigned long *console_mfn)
{
start_info_t start_info;
struct domain_setup_info dsi;
@@ -251,12 +252,34 @@ int xc_linux_build(int xc_handle,
unsigned long initrd_len = 0;
unsigned long start_info_addr;
unsigned long rma_pages;
+unsigned long shadow_mb;
int rc = 0;
+int op;
+struct ft_cxt root;
+void *devtree;
DPRINTF("%s\n", __func__);
nr_pages = mem_mb << (20 - PAGE_SHIFT);
DPRINTF("nr_pages 0x%lx\n", nr_pages);
+
+/* fetch the current shadow_memory value for this domain */
+op = XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION;
+if (xc_shadow_control(xc_handle, domid, op, NULL, 0,
&shadow_mb, 0, NULL) < 0 ) {
+rc = -1;
+goto out;
+}
+
+/* build the devtree here */
+DPRINTF("constructing devtree\n");
+if (make_devtree(&root, domid, mem_mb, shadow_mb, cmdline) < 0) {
+DPRINTF("failed to create flattened device tree\n");
+rc = -1;
+goto out;
+}
+
+/* point devtree at bph blob */
+devtree = root.bph;
rma_pages = get_rma_pages(devtree);
if (rma_pages == 0) {
@@ -314,6 +337,7 @@ int xc_linux_build(int xc_handle,
}
out:
+free_devtree(&root);
free_page_array(page_array);
return rc;
}
diff -r 3edbfb956864 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.hFri Jan 12 15:16:42 2007 -0600
+++ b/tools/libxc/xenguest.hFri Jan 12 17:08:40 2007 -0600
@@ -57,7 +57,6 @@ int xc_linux_restore(int xc_handle, int
* @parm store_mfn returned with the mfn of the store page
* @parm console_evtchn the console event channel for this domain
to use
* @parm console_mfn returned with the mfn of the console page
- * @parm arch_args architecture-specific data
* @return 0 on success, -1 on failure
*/
int xc_linux_build(int xc_handle,
@@ -71,8 +70,7 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
[XenPPC] [xenppc-unstable] [XEN][POWERPC] everything is "single core" right now so get cpu_core_map[] correct.
# HG changeset patch # User Jimi Xenidis <[EMAIL PROTECTED]> # Node ID 5568efb41da42a55318fa05d3ce0aa73e774e6d1 # Parent d6481755ade6fbe72d8e519191f12160f92cd517 [XEN][POWERPC] everything is "single core" right now so get cpu_core_map[] correct. Signed-off-by: Jimi Xenidis <[EMAIL PROTECTED]> --- xen/arch/powerpc/setup.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -r d6481755ade6 -r 5568efb41da4 xen/arch/powerpc/setup.c --- a/xen/arch/powerpc/setup.c Thu Jan 11 13:39:27 2007 -0600 +++ b/xen/arch/powerpc/setup.c Mon Jan 15 13:27:20 2007 -0500 @@ -252,7 +252,7 @@ static int kick_secondary_cpus(int maxcp cpu_set(i, cpu_sibling_map[cpuid]); /* For now everything is single core */ -cpu_set(0, cpu_core_map[cpuid]); +cpu_set(cpuid, cpu_core_map[cpuid]); numa_set_node(cpuid, 0); numa_add_cpu(cpuid); ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 4 of 4] [PATCH] Remove FlatDeviceTree.py, move prose builder to libxc devtree construction
* Ryan Harper <[EMAIL PROTECTED]> [2007-01-11 15:19]:
> * Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-11 15:11]:
> > Straight off, prose should have no flat tree reference at all.
>
> Respun with devtree refs excised.
Killed the PPC Linux image class. Left the custom class in for prose
builder as it does something different than xc_linux_build for ppc
(cmdline arg pointer in a reg IIRC).
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
a/tools/python/xen/xend/FlatDeviceTree.py | 359 --
tools/libxc/powerpc64/xc_prose_build.c| 124 --
tools/libxc/xenguest.h|3
tools/python/xen/lowlevel/xc/xc.c | 12 -
tools/python/xen/xend/image.py| 50
5 files changed, 16 insertions(+), 532 deletions(-)
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
---
[PATCH] Remove FlatDeviceTree.py, eliminate devtree from prose builder.
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
diff -r 31166b669758 tools/libxc/powerpc64/xc_prose_build.c
--- a/tools/libxc/powerpc64/xc_prose_build.cFri Jan 12 16:02:04 2007 -0600
+++ b/tools/libxc/powerpc64/xc_prose_build.cFri Jan 12 16:02:14 2007 -0600
@@ -13,7 +13,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
- * Copyright (C) IBM Corporation 2006
+ * Copyright IBM Corporation 2006
*
* Authors: Hollis Blanchard <[EMAIL PROTECTED]>
* Jonathan Appavoo <[EMAIL PROTECTED]>
@@ -34,18 +34,14 @@
#include
#include
-#include "flatdevtree_env.h"
-#include "flatdevtree.h"
#include "utils.h"
#define INITRD_ADDR (24UL << 20)
-#define DEVTREE_ADDR (16UL << 20)
static int init_boot_vcpu(
int xc_handle,
int domid,
struct domain_setup_info *dsi,
-unsigned long devtree_addr,
unsigned long kern_addr)
{
vcpu_guest_context_t ctxt;
@@ -55,7 +51,7 @@ static int init_boot_vcpu(
ctxt.user_regs.pc = dsi->v_kernentry;
ctxt.user_regs.msr = 0;
ctxt.user_regs.gprs[1] = 0; /* Linux uses its own stack */
-ctxt.user_regs.gprs[3] = devtree_addr;
+ctxt.user_regs.gprs[3] = 0;
ctxt.user_regs.gprs[4] = kern_addr;
ctxt.user_regs.gprs[5] = 0; /* reserved for specifying OF handler */
/* There is a buggy kernel that does not zero the "local_paca", so
@@ -79,85 +75,6 @@ static int init_boot_vcpu(
return rc;
}
-static int load_devtree(
-int xc_handle,
-int domid,
-xen_pfn_t *page_array,
-void *devtree,
-unsigned long devtree_addr,
-uint64_t initrd_base,
-unsigned long initrd_len,
-start_info_t *start_info __attribute__((unused)),
-unsigned long start_info_addr)
-{
-uint32_t si[4] = {0, start_info_addr, 0, 0x1000};
-struct boot_param_header *header;
-void *chosen;
-void *xen;
-uint64_t initrd_end = initrd_base + initrd_len;
-unsigned int devtree_size;
-int rc = 0;
-
-DPRINTF("adding initrd props\n");
-
-chosen = ft_find_node(devtree, "/chosen");
-if (chosen == NULL) {
-DPRINTF("couldn't find /chosen\n");
-return -1;
-}
-
-xen = ft_find_node(devtree, "/xen");
-if (xen == NULL) {
-DPRINTF("couldn't find /xen\n");
-return -1;
-}
-
-/* initrd-start */
-rc = ft_set_prop(&devtree, chosen, "linux,initrd-start",
-&initrd_base, sizeof(initrd_base));
-if (rc < 0) {
-DPRINTF("couldn't set /chosen/linux,initrd-start\n");
-return rc;
-}
-
-/* initrd-end */
-rc = ft_set_prop(&devtree, chosen, "linux,initrd-end",
-&initrd_end, sizeof(initrd_end));
-if (rc < 0) {
-DPRINTF("couldn't set /chosen/linux,initrd-end\n");
-return rc;
-}
-
-rc = ft_set_rsvmap(devtree, 1, initrd_base, initrd_len);
-if (rc < 0) {
-DPRINTF("couldn't set initrd reservation\n");
-return ~0UL;
-}
-
-/* start-info (XXX being removed soon) */
-rc = ft_set_prop(&devtree, xen, "start-info", si, sizeof(si));
-if (rc < 0) {
-DPRINTF("couldn't set /xen/start-info\n");
-return rc;
-}
-
-header = devtree;
-devtree_size = header->totalsize;
-{
-static const char dtb[] = "/tmp/xc_domU.dtb";
-int dfd = creat(dtb, 0666);
-if (dfd != -1) {
-write(dfd, devtree, devtree_size);
-close(dfd);
-} else
-DPRINTF("could not open(\"%s\")\n", dtb);
-}
-
-DPRINTF("copying device tree to 0x%lx[0x%x]\n", DEVTREE_ADDR,
devtree_size);
-return install_image(xc_handle, domid, page_array, devtree, DEVTREE_ADDR,
- devtree_size);
-}
-
static int load_initrd(
int xc_handle,
int domid,
@@ -188,13 +105,12 @@ out:
}
static unsigned long create_start_info(
- void *devtree, start_info_t *start_info,
+ start_inf
Re: [XenPPC] [PATCH 3 of 4] [PATCH] Move flat device tree construction from python to libxc for xc_linux_build()
* Jimi Xenidis <[EMAIL PROTECTED]> [2007-01-11 16:53]:
>
> Ok there are a few things here.
Respun with fixes:
- preserve and return errno where approriate
- using open/close and read/write instead of f*
- dropped vcpu argument, only fill out one cpu in devtree
- dropped regexp requirment, use a null-terminated list of filters
- made sure to call closedir()
- fixed double-free of bph on error path
- fixed static function names
- renamed find_first_cpu to find_cpu, we don't care which cpu we find
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
b/tools/libxc/powerpc64/mk_flatdevtree.c | 567 +++
b/tools/libxc/powerpc64/mk_flatdevtree.h | 44 ++
tools/libxc/powerpc64/Makefile |1
tools/libxc/powerpc64/xc_linux_build.c | 30 +
tools/libxc/xenguest.h |4
tools/python/xen/lowlevel/xc/xc.c| 12
tools/python/xen/xend/image.py |5
7 files changed, 646 insertions(+), 17 deletions(-)
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
---
[PATCH] Move flat device tree construction from python to libxc for
xc_linux_build().
Signed-off-by: Ryan Harper <[EMAIL PROTECTED]>
diff -r 3edbfb956864 tools/libxc/powerpc64/Makefile
--- a/tools/libxc/powerpc64/MakefileFri Jan 12 15:16:42 2007 -0600
+++ b/tools/libxc/powerpc64/MakefileFri Jan 12 15:16:42 2007 -0600
@@ -1,4 +1,5 @@ GUEST_SRCS-y += powerpc64/flatdevtree.c
GUEST_SRCS-y += powerpc64/flatdevtree.c
+GUEST_SRCS-y += powerpc64/mk_flatdevtree.c
GUEST_SRCS-y += powerpc64/xc_linux_build.c
GUEST_SRCS-y += powerpc64/xc_prose_build.c
GUEST_SRCS-y += powerpc64/utils.c
diff -r 3edbfb956864 tools/libxc/powerpc64/xc_linux_build.c
--- a/tools/libxc/powerpc64/xc_linux_build.cFri Jan 12 15:16:42 2007 -0600
+++ b/tools/libxc/powerpc64/xc_linux_build.cFri Jan 12 16:00:33 2007 -0600
@@ -13,9 +13,10 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
- * Copyright (C) IBM Corporation 2006
+ * Copyright IBM Corporation 2006, 2007
*
* Authors: Hollis Blanchard <[EMAIL PROTECTED]>
+ * Ryan Harper <[EMAIL PROTECTED]>
*/
#include
@@ -36,6 +37,7 @@
#include "flatdevtree_env.h"
#include "flatdevtree.h"
#include "utils.h"
+#include "mk_flatdevtree.h"
#define INITRD_ADDR (24UL << 20)
#define DEVTREE_ADDR (16UL << 20)
@@ -238,8 +240,7 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn,
- void *devtree)
+ unsigned long *console_mfn)
{
start_info_t start_info;
struct domain_setup_info dsi;
@@ -251,12 +252,34 @@ int xc_linux_build(int xc_handle,
unsigned long initrd_len = 0;
unsigned long start_info_addr;
unsigned long rma_pages;
+unsigned long shadow_mb;
int rc = 0;
+int op;
+struct ft_cxt root;
+void *devtree;
DPRINTF("%s\n", __func__);
nr_pages = mem_mb << (20 - PAGE_SHIFT);
DPRINTF("nr_pages 0x%lx\n", nr_pages);
+
+/* fetch the current shadow_memory value for this domain */
+op = XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION;
+if (xc_shadow_control(xc_handle, domid, op, NULL, 0, &shadow_mb, 0, NULL)
< 0 ) {
+rc = -1;
+goto out;
+}
+
+/* build the devtree here */
+DPRINTF("constructing devtree\n");
+if (make_devtree(&root, domid, mem_mb, shadow_mb, cmdline) < 0) {
+DPRINTF("failed to create flattened device tree\n");
+rc = -1;
+goto out;
+}
+
+/* point devtree at bph blob */
+devtree = root.bph;
rma_pages = get_rma_pages(devtree);
if (rma_pages == 0) {
@@ -314,6 +337,7 @@ int xc_linux_build(int xc_handle,
}
out:
+free_devtree(&root);
free_page_array(page_array);
return rc;
}
diff -r 3edbfb956864 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.hFri Jan 12 15:16:42 2007 -0600
+++ b/tools/libxc/xenguest.hFri Jan 12 17:08:40 2007 -0600
@@ -57,7 +57,6 @@ int xc_linux_restore(int xc_handle, int
* @parm store_mfn returned with the mfn of the store page
* @parm console_evtchn the console event channel for this domain to use
* @parm console_mfn returned with the mfn of the console page
- * @parm arch_args architecture-specific data
* @return 0 on success, -1 on failure
*/
int xc_linux_build(int xc_handle,
@@ -71,8 +70,7 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn,
- void *arch_args);
+ unsigned long *console_mfn);
/**
* This function will create
Re: [XenPPC] IPI problems
On Mon, 2007-01-15 at 11:23 -0600, Hollis Blanchard wrote:
> On Fri, 2007-01-12 at 19:41 -0500, Amos Waterland wrote:
> > On Fri, Jan 12, 2007 at 05:45:03PM -0600, Hollis Blanchard wrote:
> > > We seem to have an IPI problem, which causes vcpu_pause() to hang the
> > > system. The following patch, tested on JS20 and JS21, illustrates it.
> > > Before dom0 starts, IPIs work fine. After Linux's mpic_init(), IPIs (as
> > > triggered by the 'I' keyhandler) lock the machine. Actually, it looks
> > > like a message is trying to get out, because after a while we see a '('
> > > emitted (presumably the first character in "(XEN)").
> >
> > No, this is almost certainly our code that checks that the IPI start is
> > acked. If you run with `sync_console' you should see periodic messages
> > about start stalls.
> >
> > > (When I comment out mpic_init() in dom0, Xen IPIs continue to work but
> > > real IRQs (e.g. the IDE controller) fail in dom0.)
> >
> > Make sure you did not merge this out:
> >
> >
> > http://lists.xensource.com/archives/html/xen-ppc-devel/2006-11/msg00149.html
>
> Hmmm. I had never pulled this (Linux) changeset. However, now that I
> have, it doesn't seem to be helping.
Correction: the ^A commands work, so IPIs seem to be working.
I still have a hang under xm destroy I'm debugging.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] paravirt_ops
On Mon, 2007-01-15 at 11:21 -0700, Yoder Stuart-B08248 wrote: > Is paravirt_ops an X86 thing only? I'm assuming this ops > structure in Linux was to enable VMware and Xen to share a > common OS-to-hypervisor interface. Correct. > On Linux/powerpc we don't need this because we don't have competing > hypervisors. Correct? Actually we do have competing hypervisors: pSeries, iSeries, Xen, and of course bare metal. We have already solved this problem though, since we have function pointers for platform-specific operations like "hpte_insert". In fact we solved it so well, paravirt_ops was modeled on PowerPC's struct machdep_calls. x86 is playing catchup here. -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] paravirt_ops
Is paravirt_ops an X86 thing only? I'm assuming this ops structure in Linux was to enable VMware and Xen to share a common OS-to-hypervisor interface. On Linux/powerpc we don't need this because we don't have competing hypervisors. Correct? Thanks, Stuart ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] IPI problems
On Jan 15, 2007, at 12:37 PM, Hollis Blanchard wrote: On Fri, 2007-01-12 at 20:34 -0500, Jimi Xenidis wrote: I just built clean xenppc-unstable.hg (assuming it has the issues you state below) and all IPI ^A*3 tests (esp 't' and 'd') work just fine on my maple What about xm destroy? I can boot fine and start a domU, but xm destroy locks my system spinning in vcpu_pause(). unfortunately, the panic I posed previously does not allow me to create even a ramdisk domain so I can't destroy just yet :) ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] IPI problems
On Fri, 2007-01-12 at 20:34 -0500, Jimi Xenidis wrote: > I just built clean xenppc-unstable.hg (assuming it has the issues you > state below) and all IPI ^A*3 tests (esp 't' and 'd') work just fine > on my maple What about xm destroy? I can boot fine and start a domU, but xm destroy locks my system spinning in vcpu_pause(). -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] IPI problems
On Fri, 2007-01-12 at 19:41 -0500, Amos Waterland wrote:
> On Fri, Jan 12, 2007 at 05:45:03PM -0600, Hollis Blanchard wrote:
> > We seem to have an IPI problem, which causes vcpu_pause() to hang the
> > system. The following patch, tested on JS20 and JS21, illustrates it.
> > Before dom0 starts, IPIs work fine. After Linux's mpic_init(), IPIs (as
> > triggered by the 'I' keyhandler) lock the machine. Actually, it looks
> > like a message is trying to get out, because after a while we see a '('
> > emitted (presumably the first character in "(XEN)").
>
> No, this is almost certainly our code that checks that the IPI start is
> acked. If you run with `sync_console' you should see periodic messages
> about start stalls.
>
> > (When I comment out mpic_init() in dom0, Xen IPIs continue to work but
> > real IRQs (e.g. the IDE controller) fail in dom0.)
>
> Make sure you did not merge this out:
>
> http://lists.xensource.com/archives/html/xen-ppc-devel/2006-11/msg00149.html
Hmmm. I had never pulled this (Linux) changeset. However, now that I
have, it doesn't seem to be helping.
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
