Re: [Xen-devel] Re: [XenPPC] Xencomm for xen/ia64
Le Lundi 21 Août 2006 18:24, Hollis Blanchard a écrit : On Mon, 2006-08-21 at 08:46 +0200, Tristan Gingold wrote: Le Vendredi 18 Août 2006 18:39, Hollis Blanchard a écrit : On Fri, 2006-08-18 at 11:04 +0200, Tristan Gingold wrote: Le Jeudi 17 Août 2006 20:35, Hollis Blanchard a écrit : I'm not sure how it simplifies hcall.c. You always need to create xencomm descriptors, unless you're manually guaranteeing that the dom0_op structures do not cross page boundaries (in which case they are not linear in memory). Is that what you're doing? For hypercalls issued through privcmd, xencomm descriptors are always created. For hypercalls directly issued by kernel inline xencomm is prefered. How do you guarantee that kernel-created data structures are not crossing page boundaries? The patch you sent does not do this. Without that, xencomm_inline() simply cannot work except by luck. Kernel-created structures are linear in guest physical space, so it doesn't matter if they cross page boundaries. We need to do one more thing though: we *also* need to change fix up the size of longs and pointers in our code (since 32-bit userland is passing structures to a 64-bit kernel). So perhaps these two fixup passes could be split: we could share the xencomm conversion in common code, and PPC arch code could contain the size munging. Are structure sizes different on 32 and 64 bits ? Yes, in particular longs and pointers. But are longs and pointers used directly in Xen hypercalls ? I though only sized types (uintNN_t others) are used. I have put a lot of work into converting types to be explicitly sized, but there are still missing pieces. I think Jimi got tired of it, and started doing the Linux compat32 conversion. For example, see drivers/xen/privcmd/compat_privcmd.c . Ok. Tristan. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] RFC: xencomm - linux side
Le Lundi 21 Août 2006 21:07, Hollis Blanchard a écrit : On Mon, 2006-08-21 at 17:18 +0200, Tristan Gingold wrote: I am posting the linux xencomm code for review. I'd plan to submit soon unless comments/remarks. NAK. I'm still waiting to hear back about how you can use xencomm_inline() without worrying about page boundaries. More elaborated answer: On linux/ia64, kernel is linearly mapped into guest physical memory. The same is true for process kernel stacks. Therefore all kernels structure are linear in guest physical memory. Kernel data may of course cross page boundaries. But Xen can correctly handle this using only the guest physical address. Is something wrong ? Is something that don't apply on powerpc ? Tristan. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [POWERPC] RFC: memory clean up
This code walks the OF dev tree, finding end-of-memory and memory holes.
All memory beyond the hypervisor's RMA is added to domheap. (Previously
only memory upto 1st hole was used.) Finally, parts of setup.c have been
swept into memory.c as cleanup.
diff -r 9c72449e4370 xen/arch/powerpc/setup.c
--- a/xen/arch/powerpc/setup.c Fri Aug 18 17:52:04 2006 -0500
+++ b/xen/arch/powerpc/setup.c Tue Aug 22 09:52:03 2006 -0400
@@ -43,6 +43,7 @@
#include asm/percpu.h
#include exceptions.h
#include of-devtree.h
+#include memory.h
#define DEBUG
unsigned long xenheap_phys_end;
@@ -195,7 +196,7 @@ void startup_cpu_idle_loop(void)
reset_stack_and_jump(idle_loop);
}
-static ulong free_xenheap(ulong start, ulong end)
+ulong free_xenheap(ulong start, ulong end)
{
start = ALIGN_UP(start, PAGE_SIZE);
end = ALIGN_DOWN(end, PAGE_SIZE);
@@ -217,10 +218,6 @@ static void __init __start_xen(multiboot
{
char *cmdline;
module_t *mod = (module_t *)((ulong)mbi-mods_addr);
-ulong heap_start;
-ulong eomem = 0;
-ulong heap_size = 0;
-ulong bytes = 0;
ulong freemem;
ulong dom0_start, dom0_len;
ulong initrd_start, initrd_len;
@@ -267,61 +264,8 @@ static void __init __start_xen(multiboot
mod[mbi-mods_count-1].mod_end = 0;
--mbi-mods_count;
-printk(Physical RAM map:\n);
-
-/* lets find out how much memory there is */
-while (bytes mbi-mmap_length) {
-u64 end;
-u64 addr;
-u64 size;
-
-memory_map_t *map = (memory_map_t *)((ulong)mbi-mmap_addr + bytes);
-addr = ((u64)map-base_addr_high 32) | (u64)map-base_addr_low;
-size = ((u64)map-length_high 32) | (u64)map-length_low;
-end = addr + size;
-
-printk( %016lx - %016lx (usable)\n, addr, end);
-
-if (addr eomem) {
-printk(found a hole skipping remainder of memory at:\n
-%016lx and beyond\n, addr);
-break;
-}
-if (end eomem) {
-eomem = end;
-}
-bytes += map-size + 4;
-}
-
-printk(System RAM: %luMB (%lukB)\n, eomem 20, eomem 10);
-
-/* top of memory */
-max_page = PFN_DOWN(ALIGN_DOWN(eomem, PAGE_SIZE));
-total_pages = max_page;
-
-/* Architecturally the first 4 pages are exception hendlers, we
- * will also be copying down some code there */
-heap_start = 4 PAGE_SHIFT;
-if (oftree (ulong)_start)
-heap_start = ALIGN_UP(oftree_end, PAGE_SIZE);
-
-heap_start = init_boot_allocator(heap_start);
-if (heap_start (ulong)_start) {
-panic(space below _start (%p) is not enough memory
- for heap (0x%lx)\n, _start, heap_start);
-}
-
-/* we give the first RMA to the hypervisor */
-xenheap_phys_end = rma_size(cpu_rma_order());
-
-/* allow everything else to be allocated */
-init_boot_pages(xenheap_phys_end, eomem);
-init_frametable();
-end_boot_allocator();
-
-/* Add memory between the beginning of the heap and the beginning
- * of out text */
-free_xenheap(heap_start, (ulong)_start);
+xenheap_phys_end = setup_memory();
+
freemem = ALIGN_UP((ulong)_end, PAGE_SIZE);
for (i = 0; i mbi-mods_count; i++) {
@@ -355,10 +299,6 @@ static void __init __start_xen(multiboot
/* make sure the OF devtree is good */
ofd_walk((void *)oftree, OFD_ROOT, ofd_dump_props, OFD_DUMP_ALL);
#endif
-
-heap_size = xenheap_phys_end - heap_start;
-
-printk(Xen heap: %luMB (%lukB)\n, heap_size 20, heap_size 10);
percpu_init_areas();
./xen/arch/powerpc/memory.c:
#include xen/sched.h
#include xen/mm.h
#include of-devtree.h
#include oftree.h
#include memory.h
typedef ulong (*walk_mem_fn)(ulong *membuf, int entries, ulong ret, ulong arg);
static ulong ofd_walk_mem(void *m, walk_mem_fn fn, ulong arg);
static ulong end_of_mem(ulong *membuf, int entries, ulong end, ulong unused);
static ulong init_unused_pages(ulong *membuf, int entries, ulong ret, ulong
freemem);
ulong setup_memory(void)
{
ulong eomem, holes;
ulong heap_start, xenheap_phys_end, heap_size;
printk(Physical RAM map:\n);
/* lets find out how much memory there is */
eomem = ofd_walk_mem((void *)oftree, end_of_mem, 0 /*unused*/);
if (eomem == 0){
panic(ofd_walk_mem((void *)oftree, end_of_mem, 0 /*unused*/)
failed\n);
}
printk(End of RAM: %luMB (%lukB)\n, eomem 20, eomem 10);
/* top of memory */
max_page = PFN_DOWN(ALIGN_DOWN(eomem, PAGE_SIZE));
/* Architecturally the first 4 pages are exception hendlers, we
* will also be copying down some code there */
heap_start = 4 PAGE_SHIFT;
if (oftree (ulong)_start)
heap_start = ALIGN_UP(oftree_end, PAGE_SIZE);
heap_start = init_boot_allocator(heap_start);
if (heap_start (ulong)_start) {
panic(space below _start (%p) is not enough memory
for heap (0x%lx)\n, _start, heap_start);
}
/* we give the first
Re: [XenPPC] [PATCH] Enable SMP, smp_processor_id, for_each_cpu, nosmp, maxcpus=X
On Aug 21, 2006, at 8:12 PM, Amos Waterland wrote: Add support for the nosmp and maxcpus=X command line options, and address Hollis' concerns about comments, prototypes, and panic messages. thanks Amos, pushed. I had to follow it with a workaround for a Xen assumption so domain creation could work. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] making xen tools on dom0 can be slow
This was discussed yesterday and it was suggested that I should enter a bug for this. Since then I have done a few experiments: By default dom0 has 64M. Under these condition make tools takes 24 minutes on a js20. make[1]: Leaving directory `/home/j9/xen-ppc/tools' real24m1.321s user0m34.716s sys 0m23.272s I have found this is about the case on average. This is with the xen source tree on nfs. I dismiss this as a network related problem since I see no evidence of this. By changing xen to give 128M to each domain and therefore to dom0, the same make, also with source over nfs takes less than 2 minutes. make[1]: Leaving directory `/home/j9/xen-ppc/tools' real1m15.445s user0m32.800s sys 0m14.753s I will not enter this as a bug. If anything the bug is that one might not specify the memory size for dom0. (On a related note, once we alter xen to give each domain 128M, xm create no longer works. Jimi is debugging this.) Also I reported slowness for starting xend. I am still working with this and will post to the list as soon as I have more data. Simply giving more memory to dom0 does not fix the slow xend start problem. Maria Butricointernet or sametime: [EMAIL PROTECTED]; Notes: Maria Butrico/Watson/IBM ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [POWERPC] Take all secondary processors offline after they are enumerated
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID 13d64dec47117e45d04e934f90a96eb042d7bf41
# Parent e65f030855fb11b708332a1f0453d33659b499a8
[POWERPC] Take all secondary processors offline after they are enumerated
Xen assumes that an online CPU is a schedualable CPU, but we just are
not there yet. Remove this fragment when scheduling processors
actually works.
Signed-off-by: Jimi Xenidis [EMAIL PROTECTED]
---
xen/arch/powerpc/setup.c | 15 +++
1 files changed, 15 insertions(+)
diff -r e65f030855fb -r 13d64dec4711 xen/arch/powerpc/setup.c
--- a/xen/arch/powerpc/setup.c Tue Aug 22 09:53:34 2006 -0400
+++ b/xen/arch/powerpc/setup.c Tue Aug 22 11:16:01 2006 -0400
@@ -182,6 +182,21 @@ static void __init start_of_day(void)
percpu_free_unused_areas();
+{
+/* FIXME: Xen assumes that an online CPU is a schedualable
+ * CPU, but we just are not there yet. Remove this fragment when
+ * scheduling processors actually works. */
+int cpuid;
+
+printk(WARNING!: Taking all secondary CPUs offline\n);
+
+for_each_online_cpu(cpuid) {
+if (cpuid == 0)
+continue;
+cpu_clear(cpuid, cpu_online_map);
+}
+}
+
initialize_keytable();
/* Register another key that will allow for the the Harware Probe
* to be contacted, this works with RiscWatch probes and should
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [POWERPC] Enable SMP, smp_processor_id, for_each_cpu, nosmp, maxcpus=X
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID e65f030855fb11b708332a1f0453d33659b499a8
# Parent 326e6736d92bf8079ff360292aeeaef3b2958bb4
[POWERPC] Enable SMP, smp_processor_id, for_each_cpu, nosmp, maxcpus=X
Add support for the nosmp and maxcpus=X command line options, and
address Hollis' concerns about comments, prototypes, and panic messages.
Handshake with secondary processors, move all of them out of their OF
spinloop even if there are more of them than NR_CPUS, enumerate them
according to a logical rather than firmware numerical space, give them a
stack, make them run C code to initialize their HIDs, initialize their
r13 registers to a per-processor pointer, enable smp_processor_id and
and properly set the maps of present and online CPUs.
Tested on 2-way JS20, 4-way JS21, and 16-way systemsim-gpul, with
NR_CPUS from 1 to 64, nosmp, and maxcpus from 1 to 3.
Signed-off-by: Amos Waterland [EMAIL PROTECTED]
---
xen/arch/powerpc/boot_of.c | 67 +++--
xen/arch/powerpc/powerpc64/exceptions.S | 37 ++
xen/arch/powerpc/powerpc64/ppc970.c | 22
xen/arch/powerpc/setup.c | 71 ++-
xen/include/asm-powerpc/config.h |2
xen/include/asm-powerpc/current.h|2
xen/include/asm-powerpc/powerpc64/procarea.h |1
xen/include/asm-powerpc/processor.h |2
xen/include/asm-powerpc/smp.h|4 -
9 files changed, 188 insertions(+), 20 deletions(-)
diff -r 326e6736d92b -r e65f030855fb xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cMon Aug 21 10:04:37 2006 -0400
+++ b/xen/arch/powerpc/boot_of.cTue Aug 22 09:53:34 2006 -0400
@@ -31,6 +31,9 @@
#include asm/io.h
#include exceptions.h
#include of-devtree.h
+
+/* Secondary processors use this for handshaking with main processor. */
+volatile unsigned int __spin_ack;
static ulong of_vec;
static ulong of_msr;
@@ -955,7 +958,7 @@ static int __init boot_of_cpus(void)
static int __init boot_of_cpus(void)
{
int cpus;
-int cpu;
+int cpu, bootcpu, logical;
int result;
u32 cpu_clock[2];
@@ -980,10 +983,65 @@ static int __init boot_of_cpus(void)
cpu_khz /= 1000;
of_printf(OF: clock-frequency = %ld KHz\n, cpu_khz);
-/* FIXME: should not depend on the boot CPU bring the first child */
+/* Look up which CPU we are running on right now. */
+result = of_getprop(bof_chosen, cpu, bootcpu, sizeof (bootcpu));
+if (result == OF_FAILURE)
+of_panic(Failed to look up boot cpu\n);
+
cpu = of_getpeer(cpu);
-while (cpu 0) {
-of_start_cpu(cpu, (ulong)spin_start, 0);
+
+/* We want a continuous logical cpu number space. */
+cpu_set(0, cpu_present_map);
+cpu_set(0, cpu_online_map);
+
+/* Spin up all CPUS, even if there are more than NR_CPUS, because
+ * Open Firmware has them spinning on cache lines which will
+ * eventually be scrubbed, which could lead to random CPU activation.
+ */
+for (logical = 1; cpu 0; logical++) {
+unsigned int cpuid, ping, pong;
+unsigned long now, then, timeout;
+
+if (cpu == bootcpu) {
+of_printf(skipping boot cpu!\n);
+continue;
+}
+
+result = of_getprop(cpu, reg, cpuid, sizeof(cpuid));
+if (result == OF_FAILURE)
+of_panic(cpuid lookup failed\n);
+
+of_printf(spinning up secondary processor #%d: , logical);
+
+__spin_ack = ~0x0;
+ping = __spin_ack;
+pong = __spin_ack;
+of_printf(ping = 0x%x: , ping);
+
+mb();
+result = of_start_cpu(cpu, (ulong)spin_start, logical);
+if (result == OF_FAILURE)
+of_panic(start cpu failed\n);
+
+/* We will give the secondary processor five seconds to reply. */
+then = mftb();
+timeout = then + (5 * timebase_freq);
+
+do {
+now = mftb();
+if (now = timeout) {
+of_printf(BROKEN: );
+break;
+}
+
+mb();
+pong = __spin_ack;
+} while (pong == ping);
+of_printf(pong = 0x%x\n, pong);
+
+if (pong != ping)
+cpu_set(logical, cpu_present_map);
+
cpu = of_getpeer(cpu);
}
return 1;
@@ -1031,6 +1089,7 @@ multiboot_info_t __init *boot_of_init(
boot_of_rtas();
/* end of OF */
+of_printf(Quiescing Open Firmware ...\n);
of_call(quiesce, 0, 0, NULL);
return mbi;
diff -r 326e6736d92b -r e65f030855fb xen/arch/powerpc/powerpc64/exceptions.S
--- a/xen/arch/powerpc/powerpc64/exceptions.S Mon Aug 21 10:04:37 2006 -0400
+++ b/xen/arch/powerpc/powerpc64/exceptions.S Tue Aug 22 09:53:34 2006 -0400
@@ -514,6 +514,43 @@ _GLOBAL(sleep)
mtmsrd r3
blr
+/* The primary processor issues a firmware call to spin us up at this
+ * address, passing our
[XenPPC] [xenppc-unstable] [POWERPC] Explain the RMA values a little more
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID 6eccd4911e6c084bcc3d8bc1de8bbdb6e343f132
# Parent 13d64dec47117e45d04e934f90a96eb042d7bf41
[POWERPC] Explain the RMA values a little more
Since I did not understand them myself.
Signed-off-by: Jimi Xenidis [EMAIL PROTECTED]
---
xen/arch/powerpc/powerpc64/ppc970.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff -r 13d64dec4711 -r 6eccd4911e6c xen/arch/powerpc/powerpc64/ppc970.c
--- a/xen/arch/powerpc/powerpc64/ppc970.c Tue Aug 22 11:16:01 2006 -0400
+++ b/xen/arch/powerpc/powerpc64/ppc970.c Tue Aug 22 11:17:09 2006 -0400
@@ -13,9 +13,10 @@
* 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
+ * Copyright (C) IBM Corp. 2005, 2006
*
* Authors: Hollis Blanchard [EMAIL PROTECTED]
+ * Jimi Xenidis [EMAIL PROTECTED]
*/
#include xen/config.h
@@ -36,7 +37,7 @@ unsigned int cpu_rma_order(void)
unsigned int cpu_rma_order(void)
{
/* XXX what about non-HV mode? */
-uint rma_log_size = 6 + 20; /* 64M */
+uint rma_log_size = 6 + 20; /* (1 6) == 64 */
return rma_log_size - PAGE_SHIFT;
}
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] making xen tools on dom0 can be slow
On Tue, 2006-08-22 at 11:48 -0400, Maria Butrico wrote: By default dom0 has 64M. Under these condition make tools takes 24 minutes on a js20. Wow, that's terrible. Just as a data point, is the time more reasonable if you copy the source first then build locally? -- 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] Fix domU device tree creation for JS20/1
On Mon, 2006-08-21 at 19:34 -0400, Maria Butrico wrote:
Summary: Fix device tree creation for domU for js20/1 under SLOF
The device tree of dom0 on js20 and js21 with SLOF does not have the cpus'
d and i cache sets nor does it have the l2 cache subdirectory.
Hi Maria, please try this patch. It's a little noisy (I made printing
work for better debugging), but if it works for you I'll split it up and
check it in.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff -r 6eccd4911e6c tools/python/xen/xend/FlatDeviceTree.py
--- a/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 11:17:09 2006 -0400
+++ b/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 11:22:24 2006 -0500
@@ -20,8 +20,10 @@ import os
import os
import sys
import struct
-
-_OF_DT_HEADER = 0xd00dfeed
+import stat
+import re
+
+_OF_DT_HEADER = int(d00dfeed, 16) # avoid signed/unsigned FutureWarning
_OF_DT_BEGIN_NODE = 0x1
_OF_DT_END_NODE = 0x2
_OF_DT_PROP = 0x3
@@ -50,12 +52,40 @@ def _pad(buf, alignment):
# not present in Python 2.3:
#return buf.ljust(_padlen, '\0')
+def _indent(item):
+indented = []
+for line in str(item).splitlines(True):
+indented.append('' + line)
+return ''.join(indented)
+
class _Property:
+_nonprint = re.compile('[\000-\037\200-\377]')
def __init__(self, node, name, value):
self.node = node
self.value = value
self.name = name
self.node.tree.stradd(name)
+
+def __str__(self):
+result = self.name
+if self.value:
+searchtext = self.value
+# it's ok for a string to end in NULL
+if searchtext.find('\000') == len(searchtext)-1:
+searchtext = searchtext[:-1]
+m = self._nonprint.search(searchtext)
+if m:
+bytes = struct.unpack(B * len(self.value), self.value)
+hexbytes = [ '%02x' % b for b in bytes ]
+words = []
+for i in range(0, len(self.value), 4):
+words.append(''.join(hexbytes[i:i+4]))
+v = '' + ' '.join(words) + ''
+else:
+v = '%s' % self.value
+result += ': ' + v
+return result
+
def to_bin(self):
offset = self.node.tree.stroffset(self.name)
return struct.pack('III', _OF_DT_PROP, len(self.value), offset) \
@@ -68,6 +98,12 @@ class _Node:
self.props = {}
self.children = {}
self.phandle = 0
+
+def __str__(self):
+propstrs = [ _indent(prop) for prop in self.props.values() ]
+childstrs = [ _indent(child) for child in self.children.values() ]
+return '%s:\n%s\n%s' % (self.name, '\n'.join(propstrs),
+'\n'.join(childstrs))
def to_bin(self):
name = _pad(self.name + '\0', 4)
@@ -203,6 +239,22 @@ def _getprop(propname):
f.close()
return data
+def _copynode(node, dirpath, propfilter):
+'''Extract all properties from a node in the system's device tree.'''
+dirents = os.listdir(dirpath)
+for dirent in dirents:
+fullpath = os.path.join(dirpath, dirent)
+st = os.lstat(fullpath)
+if stat.S_ISDIR(st.st_mode):
+child = node.addnode(dirent)
+_copytree(child, fullpath, propfilter)
+elif stat.S_ISREG(st.st_mode) and propfilter(fullpath):
+node.addprop(dirent, _getprop(fullpath))
+
+def _copytree(node, dirpath, propfilter):
+path = os.path.join(_host_devtree_root, dirpath)
+_copynode(node, path, propfilter)
+
def build(imghandler):
'''Construct a device tree by combining the domain's configuration and
the host's device tree.'''
@@ -236,33 +288,20 @@ def build(imghandler):
cpus.addprop('#size-cells', 0)
cpus.addprop('#address-cells', 1)
-# create a cpu node for each vcpu
+# Copy all properties the system firmware gave us, except for 'linux,'
+# properties, from 'cpus/@0', once for every vcpu. Hopefully all cpus are
+# identical...
cpu0 = None
+def _nolinuxprops(fullpath):
+if os.path.basename(fullpath).startswith('linux,'):
+return False
+return True
for i in range(imghandler.vm.getVCpuCount()):
cpu = cpus.addnode('PowerPC,[EMAIL PROTECTED]')
+_copytree(cpu, 'cpus/PowerPC,[EMAIL PROTECTED]', _nolinuxprops)
+# and then overwrite what we need to
pft_size = imghandler.vm.info.get('pft-size', 0x14)
-cpu.addprop('ibm,pft-size', 0, pft_size)
-cpu.addprop('reg', i)
-cpu.addprop('cpu#', i)
-cpu.addprop('device_type', 'cpu\0')
-for prop in ('d-cache-size', 'd-cache-line-size', 'd-cache-sets',
- 'i-cache-size', 'i-cache-line-size', 'i-cache-sets',
- 'clock-frequency', 'timebase-frequency',
- 'timebases-in-sync'):
-val = _getprop(os.path.join('cpus/PowerPC,[EMAIL PROTECTED]',
prop))
-
Re: [XenPPC] making xen tools on dom0 can be slow
Maria Butrico wrote: This was discussed yesterday and it was suggested that I should enter a bug for this. Since then I have done a few experiments: By default dom0 has 64M. Under these condition make tools takes 24 minutes on a js20. make[1]: Leaving directory `/home/j9/xen-ppc/tools' real24m1.321s user0m34.716s sys 0m23.272s I have found this is about the case on average. This is with the xen source tree on nfs. I dismiss this as a network related problem since I see no evidence of this. By changing xen to give 128M to each domain and therefore to dom0, the same make, also with source over nfs takes less than 2 minutes. make[1]: Leaving directory `/home/j9/xen-ppc/tools' real1m15.445s user0m32.800s sys 0m14.753s I will not enter this as a bug. If anything the bug is that one might not specify the memory size for dom0. (On a related note, once we alter xen to give each domain 128M, xm create no longer works. Jimi is debugging this.) Also I reported slowness for starting xend. I am still working with this and will post to the list as soon as I have more data. Simply giving more memory to dom0 does not fix the slow xend start problem. Maria Butricointernet or sametime: [EMAIL PROTECTED]; Notes: Maria Butrico/Watson/IBM ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel Jimi and I have looked more carefully at the xend startup problem. xend is very slow if the tools or any part of the environment variable PATH are in an nfs mounted directory. Xend starts in reasonable time if the tools are local and no part of the PATH environment variable points a to a remote directory. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] RFC: xencomm - linux side
On Tue, 2006-08-22 at 09:42 +0200, Tristan Gingold wrote: Le Lundi 21 Août 2006 21:07, Hollis Blanchard a écrit : On Mon, 2006-08-21 at 17:18 +0200, Tristan Gingold wrote: I am posting the linux xencomm code for review. I'd plan to submit soon unless comments/remarks. NAK. I'm still waiting to hear back about how you can use xencomm_inline() without worrying about page boundaries. More elaborated answer: On linux/ia64, kernel is linearly mapped into guest physical memory. The same is true for process kernel stacks. Therefore all kernels structure are linear in guest physical memory. Kernel data may of course cross page boundaries. But Xen can correctly handle this using only the guest physical address. I see, and you handle this by breaking up copies at page granularity in xencomm_copy_from_user(). I have to say I don't really like the code complexity, or the fact that there are now two very different ways to access guest handles. That being said, it sure would be nice to get rid of that mini stack-based stuff, so it's OK with me. I would be surprised if there were any performance difference, however. I'll send some comments to your original patch. -- 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] RFC: xencomm - linux side
I apologize for my mailer line-wrapping the patch as I quote it below. On Mon, 2006-08-21 at 17:18 +0200, Tristan Gingold wrote: diff -r b7db009d622c linux-2.6-xen-sparse/drivers/xen/Kconfig --- a/linux-2.6-xen-sparse/drivers/xen/Kconfig Mon Aug 21 09:41:24 2006 +0200 +++ b/linux-2.6-xen-sparse/drivers/xen/Kconfig Mon Aug 21 15:04:32 2006 +0200 @@ -257,4 +257,7 @@ config XEN_SMPBOOT default y depends on SMP +config XEN_XENCOMM + bool + default n endif Shouldn't IA64 select XEN_XENCOMM? Or is your kernel in a separate tree? diff -r b7db009d622c linux-2.6-xen-sparse/drivers/xen/Makefile --- a/linux-2.6-xen-sparse/drivers/xen/Makefile Mon Aug 21 09:41:24 2006 +0200 +++ b/linux-2.6-xen-sparse/drivers/xen/Makefile Mon Aug 21 15:04:32 2006 +0200 @@ -1,10 +1,10 @@ obj-y += core/ obj-y += core/ obj-y += console/ obj-y += evtchn/ -obj-y += privcmd/ obj-y += xenbus/ obj-$(CONFIG_XEN_UTIL) += util.o +obj-$(CONFIG_XEN_PRIVCMD) += privcmd/ obj-$(CONFIG_XEN_BALLOON) += balloon/ obj-$(CONFIG_XEN_DEVMEM) += char/ obj-$(CONFIG_XEN_BLKDEV_BACKEND) += blkback/ Not really part of this patch. diff -r b7db009d622c linux-2.6-xen-sparse/drivers/xen/core/Makefile --- a/linux-2.6-xen-sparse/drivers/xen/core/MakefileMon Aug 21 09:41:24 2006 +0200 +++ b/linux-2.6-xen-sparse/drivers/xen/core/MakefileMon Aug 21 15:04:32 2006 +0200 @@ -11,3 +11,4 @@ obj-$(CONFIG_XEN_SKBUFF) += skbuff.o obj-$(CONFIG_XEN_SKBUFF) += skbuff.o obj-$(CONFIG_XEN_REBOOT) += reboot.o obj-$(CONFIG_XEN_SMPBOOT) += smpboot.o +obj-$(CONFIG_XEN_XENCOMM) += xencomm.o xencomm_hcall.o diff -r b7db009d622c linux-2.6-xen-sparse/drivers/xen/privcmd/Makefile --- a/linux-2.6-xen-sparse/drivers/xen/privcmd/Makefile Mon Aug 21 09:41:24 2006 +0200 +++ b/linux-2.6-xen-sparse/drivers/xen/privcmd/Makefile Mon Aug 21 15:04:32 2006 +0200 @@ -1,2 +1,3 @@ +obj-y := privcmd.o -obj-$(CONFIG_XEN_PRIVCMD) := privcmd.o +obj-$(CONFIG_XEN_XENCOMM) += xencomm.o I agree with the CONFIG_XEN_PRIVCMD stuff, but I think that should be a separate patch. diff -r b7db009d622c linux-2.6-xen-sparse/drivers/xen/privcmd/privcmd.c --- a/linux-2.6-xen-sparse/drivers/xen/privcmd/privcmd.cMon Aug 21 09:41:24 2006 +0200 +++ b/linux-2.6-xen-sparse/drivers/xen/privcmd/privcmd.cMon Aug 21 15:04:32 2006 +0200 @@ -34,6 +34,10 @@ static struct proc_dir_entry *privcmd_intf; static struct proc_dir_entry *capabilities_intf; + +#ifdef CONFIG_XEN_XENCOMM +extern int xencomm_privcmd_hypercall(privcmd_hypercall_t *hypercall); +#endif #define NR_HYPERCALLS 64 static DECLARE_BITMAP(hypercall_permission_map, NR_HYPERCALLS); @@ -91,19 +95,8 @@ static int privcmd_ioctl(struct inode *i g ((unsigned long)hypercall.arg[4]) : r8, r10, memory ); } -#elif defined (__ia64__) - __asm__ __volatile__ ( - ;; mov r14=%2; mov r15=%3; - mov r16=%4; mov r17=%5; mov r18=%6; - mov r2=%1; break 0x1000;; mov %0=r8 ;; - : =r (ret) - : r (hypercall.op), - r (hypercall.arg[0]), - r (hypercall.arg[1]), - r (hypercall.arg[2]), - r (hypercall.arg[3]), - r (hypercall.arg[4]) - : r14,r15,r16,r17,r18,r2,r8,memory); +#elif defined (CONFIG_XEN_XENCOMM) + ret = xencomm_privcmd_hypercall (hypercall); #endif } break; Move all the #ifdef stuff into appropriate header files, then have every arch unconditionally call arch_privcmd_hypercall(). diff -r b7db009d622c linux-2.6-xen-sparse/drivers/xen/core/xencomm.c --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/linux-2.6-xen-sparse/drivers/xen/core/xencomm.c Mon Aug 21 15:04:32 2006 +0200 @@ -0,0 +1,213 @@ +/* + * Copyright (C) 2006 Hollis Blanchard [EMAIL PROTECTED], IBM Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include
Re: [XenPPC] [PATCH] Fix domU device tree creation for JS20/1
On Tue, 2006-08-22 at 11:31 -0500, Hollis Blanchard wrote:
Hi Maria, please try this patch. It's a little noisy (I made printing
work for better debugging), but if it works for you I'll split it up
and check it in.
Thanks for testing, Maria. I've committed and pushed this patch, so you
should back out your local changes before pulling ('hg revert
tools/python/xen/xend/FlatDeviceTree.py').
--
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] [xenppc-unstable] [XEND][POWERPC] remove python warning
# HG changeset patch # User Hollis Blanchard [EMAIL PROTECTED] # Node ID e0973ea10547390bb50722d7622edf5adb2e47de # Parent 7a77cf4a7428fff092aa94226ed29a6e333c56e7 [XEND][POWERPC] remove python warning Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] --- tools/python/xen/xend/FlatDeviceTree.py |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -r 7a77cf4a7428 -r e0973ea10547 tools/python/xen/xend/FlatDeviceTree.py --- a/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 14:43:22 2006 -0500 +++ b/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 14:44:11 2006 -0500 @@ -22,7 +22,7 @@ import struct import struct import re -_OF_DT_HEADER = 0xd00dfeed +_OF_DT_HEADER = int(d00dfeed, 16) # avoid signed/unsigned FutureWarning _OF_DT_BEGIN_NODE = 0x1 _OF_DT_END_NODE = 0x2 _OF_DT_PROP = 0x3 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [XEND][POWERPC] copy all cpu properties from system device tree
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Node ID b985b2e85bf343f136ec2ceb55176edb62832f81
# Parent e0973ea10547390bb50722d7622edf5adb2e47de
[XEND][POWERPC] copy all cpu properties from system device tree
- fixes problem with newer versions of SLOF firmware, which don't export all
the properties older versions did
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
tools/python/xen/xend/FlatDeviceTree.py | 48
1 files changed, 25 insertions(+), 23 deletions(-)
diff -r e0973ea10547 -r b985b2e85bf3 tools/python/xen/xend/FlatDeviceTree.py
--- a/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 14:44:11 2006 -0500
+++ b/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 14:51:26 2006 -0500
@@ -20,6 +20,7 @@ import os
import os
import sys
import struct
+import stat
import re
_OF_DT_HEADER = int(d00dfeed, 16) # avoid signed/unsigned FutureWarning
@@ -238,6 +239,22 @@ def _getprop(propname):
f.close()
return data
+def _copynode(node, dirpath, propfilter):
+'''Extract all properties from a node in the system's device tree.'''
+dirents = os.listdir(dirpath)
+for dirent in dirents:
+fullpath = os.path.join(dirpath, dirent)
+st = os.lstat(fullpath)
+if stat.S_ISDIR(st.st_mode):
+child = node.addnode(dirent)
+_copytree(child, fullpath, propfilter)
+elif stat.S_ISREG(st.st_mode) and propfilter(fullpath):
+node.addprop(dirent, _getprop(fullpath))
+
+def _copytree(node, dirpath, propfilter):
+path = os.path.join(_host_devtree_root, dirpath)
+_copynode(node, path, propfilter)
+
def build(imghandler):
'''Construct a device tree by combining the domain's configuration and
the host's device tree.'''
@@ -271,33 +288,18 @@ def build(imghandler):
cpus.addprop('#size-cells', 0)
cpus.addprop('#address-cells', 1)
-# create a cpu node for each vcpu
+# Copy all properties the system firmware gave us, except for 'linux,'
+# properties, from 'cpus/@0', once for every vcpu. Hopefully all cpus are
+# identical...
cpu0 = None
+def _nolinuxprops(fullpath):
+return not os.path.basename(fullpath).startswith('linux,'):
for i in range(imghandler.vm.getVCpuCount()):
cpu = cpus.addnode('PowerPC,[EMAIL PROTECTED]')
+_copytree(cpu, 'cpus/PowerPC,[EMAIL PROTECTED]', _nolinuxprops)
+# and then overwrite what we need to
pft_size = imghandler.vm.info.get('pft-size', 0x14)
-cpu.addprop('ibm,pft-size', 0, pft_size)
-cpu.addprop('reg', i)
-cpu.addprop('cpu#', i)
-cpu.addprop('device_type', 'cpu\0')
-for prop in ('d-cache-size', 'd-cache-line-size', 'd-cache-sets',
- 'i-cache-size', 'i-cache-line-size', 'i-cache-sets',
- 'clock-frequency', 'timebase-frequency',
- 'timebases-in-sync'):
-val = _getprop(os.path.join('cpus/PowerPC,[EMAIL PROTECTED]',
prop))
-cpu.addprop(prop, val)
-# XXX 64-bit, more
-
-# L2 cache
-l2 = cpu.addnode('l2-cache')
-l2.addprop('name', 'l2-cache\0')
-l2.addprop('device_type', 'cache\0')
-for prop in ('d-cache-size', 'd-cache-sets',
- 'i-cache-size', 'i-cache-sets',
- 'cache-unified'):
-fullprop = os.path.join('cpus/PowerPC,[EMAIL PROTECTED]/l2-cache'
% i, prop)
-val = _getprop(fullprop)
-l2.addprop(prop, val)
+cpu.setprop('ibm,pft-size', 0, pft_size)
# set default CPU
if cpu0 == None:
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [XEND][POWERPC] nicely display flat device tree
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Node ID 7a77cf4a7428fff092aa94226ed29a6e333c56e7
# Parent 6eccd4911e6c084bcc3d8bc1de8bbdb6e343f132
[XEND][POWERPC] nicely display flat device tree
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
tools/python/xen/xend/FlatDeviceTree.py | 35
1 files changed, 35 insertions(+)
diff -r 6eccd4911e6c -r 7a77cf4a7428 tools/python/xen/xend/FlatDeviceTree.py
--- a/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 11:17:09 2006 -0400
+++ b/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 14:43:22 2006 -0500
@@ -20,6 +20,7 @@ import os
import os
import sys
import struct
+import re
_OF_DT_HEADER = 0xd00dfeed
_OF_DT_BEGIN_NODE = 0x1
@@ -50,12 +51,40 @@ def _pad(buf, alignment):
# not present in Python 2.3:
#return buf.ljust(_padlen, '\0')
+def _indent(item):
+indented = []
+for line in str(item).splitlines(True):
+indented.append('' + line)
+return ''.join(indented)
+
class _Property:
+_nonprint = re.compile('[\000-\037\200-\377]')
def __init__(self, node, name, value):
self.node = node
self.value = value
self.name = name
self.node.tree.stradd(name)
+
+def __str__(self):
+result = self.name
+if self.value:
+searchtext = self.value
+# it's ok for a string to end in NULL
+if searchtext.find('\000') == len(searchtext)-1:
+searchtext = searchtext[:-1]
+m = self._nonprint.search(searchtext)
+if m:
+bytes = struct.unpack(B * len(self.value), self.value)
+hexbytes = [ '%02x' % b for b in bytes ]
+words = []
+for i in range(0, len(self.value), 4):
+words.append(''.join(hexbytes[i:i+4]))
+v = '' + ' '.join(words) + ''
+else:
+v = '%s' % self.value
+result += ': ' + v
+return result
+
def to_bin(self):
offset = self.node.tree.stroffset(self.name)
return struct.pack('III', _OF_DT_PROP, len(self.value), offset) \
@@ -68,6 +97,12 @@ class _Node:
self.props = {}
self.children = {}
self.phandle = 0
+
+def __str__(self):
+propstrs = [ _indent(prop) for prop in self.props.values() ]
+childstrs = [ _indent(child) for child in self.children.values() ]
+return '%s:\n%s\n%s' % (self.name, '\n'.join(propstrs),
+'\n'.join(childstrs))
def to_bin(self):
name = _pad(self.name + '\0', 4)
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Fwd: [Xen-devel] 3.0.3 freeze
The code that we have upstream in xen-unstable right now will not successfully launch a domU, and because those changes will be relatively invasive (especially splitting xc_linux_build()), I will not be trying to fix that before 3.0.3 is released (which will likely be weeks at least). I don't expect anybody here much cares, but just letting folks know what's going on. Carry on with xenppc-unstable... :) -- Hollis Blanchard IBM Linux Technology Center Forwarded Message From: Ian Pratt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Xen-devel] 3.0.3 freeze Date: Tue, 22 Aug 2006 17:03:27 +0100 Folks, I think its time to declare a 3.0.3 feature freeze. We've got all the 'must have' feature patches in -unstable and many of the 'would be nice' variety too. Just to summarize, we have: the new scheduler, blktap with file-based VM storage, upgraded device emulation, new shadow pagetable code, PV drivers for HVM guests, networking support for segmentation offload, support for the Power architecture, misc performance optimizations and bug fixes. There were a number of patches that haven't quite made the cut off due to various outstanding issues or lack of review time: The NUMA allocator patch has been observed to cause problems on at least one system. The PV framebuffer could do with a few interface tweaks and a code cleanup. The kexec/kdump patch just needs more testing [I feel bad about this one -- maybe we can retrofit it]. The xend lifecycle management patches will be held-over to the next release so it can become part of a larger set of control tool changes. Now the tree is in 'freeze' state, please can everyone get ready to do some serious testing. We're still working on a handful of known issues we can reproduce, so this message isn't quite a full call to arms for testing from the user community yet, but it would be great if developers could start giving it a workout. Thanks, Ian ___ Xen-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [merge] conflict
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID e06e2cca9f39d56344ec96b90ad4a2405b247996
# Parent f2527015891cfd68f4576a8c63d3ee60e99841e2
# Parent b985b2e85bf343f136ec2ceb55176edb62832f81
[merge] conflict
---
tools/python/xen/xend/FlatDeviceTree.py | 87 ++--
1 files changed, 62 insertions(+), 25 deletions(-)
diff -r f2527015891c -r e06e2cca9f39 tools/python/xen/xend/FlatDeviceTree.py
--- a/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 17:20:58 2006 -0400
+++ b/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 17:26:36 2006 -0400
@@ -20,8 +20,10 @@ import os
import os
import sys
import struct
-
-_OF_DT_HEADER = 0xd00dfeed
+import stat
+import re
+
+_OF_DT_HEADER = int(d00dfeed, 16) # avoid signed/unsigned FutureWarning
_OF_DT_BEGIN_NODE = 0x1
_OF_DT_END_NODE = 0x2
_OF_DT_PROP = 0x3
@@ -50,12 +52,40 @@ def _pad(buf, alignment):
# not present in Python 2.3:
#return buf.ljust(_padlen, '\0')
+def _indent(item):
+indented = []
+for line in str(item).splitlines(True):
+indented.append('' + line)
+return ''.join(indented)
+
class _Property:
+_nonprint = re.compile('[\000-\037\200-\377]')
def __init__(self, node, name, value):
self.node = node
self.value = value
self.name = name
self.node.tree.stradd(name)
+
+def __str__(self):
+result = self.name
+if self.value:
+searchtext = self.value
+# it's ok for a string to end in NULL
+if searchtext.find('\000') == len(searchtext)-1:
+searchtext = searchtext[:-1]
+m = self._nonprint.search(searchtext)
+if m:
+bytes = struct.unpack(B * len(self.value), self.value)
+hexbytes = [ '%02x' % b for b in bytes ]
+words = []
+for i in range(0, len(self.value), 4):
+words.append(''.join(hexbytes[i:i+4]))
+v = '' + ' '.join(words) + ''
+else:
+v = '%s' % self.value
+result += ': ' + v
+return result
+
def to_bin(self):
offset = self.node.tree.stroffset(self.name)
return struct.pack('III', _OF_DT_PROP, len(self.value), offset) \
@@ -68,6 +98,12 @@ class _Node:
self.props = {}
self.children = {}
self.phandle = 0
+
+def __str__(self):
+propstrs = [ _indent(prop) for prop in self.props.values() ]
+childstrs = [ _indent(child) for child in self.children.values() ]
+return '%s:\n%s\n%s' % (self.name, '\n'.join(propstrs),
+'\n'.join(childstrs))
def to_bin(self):
name = _pad(self.name + '\0', 4)
@@ -203,6 +239,22 @@ def _getprop(propname):
f.close()
return data
+def _copynode(node, dirpath, propfilter):
+'''Extract all properties from a node in the system's device tree.'''
+dirents = os.listdir(dirpath)
+for dirent in dirents:
+fullpath = os.path.join(dirpath, dirent)
+st = os.lstat(fullpath)
+if stat.S_ISDIR(st.st_mode):
+child = node.addnode(dirent)
+_copytree(child, fullpath, propfilter)
+elif stat.S_ISREG(st.st_mode) and propfilter(fullpath):
+node.addprop(dirent, _getprop(fullpath))
+
+def _copytree(node, dirpath, propfilter):
+path = os.path.join(_host_devtree_root, dirpath)
+_copynode(node, path, propfilter)
+
def build(imghandler):
'''Construct a device tree by combining the domain's configuration and
the host's device tree.'''
@@ -236,33 +288,18 @@ def build(imghandler):
cpus.addprop('#size-cells', 0)
cpus.addprop('#address-cells', 1)
-# create a cpu node for each vcpu
+# Copy all properties the system firmware gave us, except for 'linux,'
+# properties, from 'cpus/@0', once for every vcpu. Hopefully all cpus are
+# identical...
cpu0 = None
+def _nolinuxprops(fullpath):
+return not os.path.basename(fullpath).startswith('linux,'):
for i in range(imghandler.vm.getVCpuCount()):
cpu = cpus.addnode('PowerPC,[EMAIL PROTECTED]')
+_copytree(cpu, 'cpus/PowerPC,[EMAIL PROTECTED]', _nolinuxprops)
+# and then overwrite what we need to
pft_size = imghandler.vm.info.get('pft-size', 0x14)
-cpu.addprop('ibm,pft-size', 0, pft_size)
-cpu.addprop('reg', i)
-cpu.addprop('cpu#', i)
-cpu.addprop('device_type', 'cpu\0')
-for prop in ('d-cache-size', 'd-cache-line-size', 'd-cache-sets',
- 'i-cache-size', 'i-cache-line-size', 'i-cache-sets',
- 'clock-frequency', 'timebase-frequency',
- 'timebases-in-sync'):
-val = _getprop(os.path.join('cpus/PowerPC,[EMAIL PROTECTED]',
prop))
-cpu.addprop(prop, val)
-# XXX 64-bit, more
-
-# L2 cache
-l2 = cpu.addnode('l2-cache')
-
[XenPPC] [xenppc-unstable] [POWERPC] Find all of memory and feed all the heaps
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID f2527015891cfd68f4576a8c63d3ee60e99841e2
# Parent 6eccd4911e6c084bcc3d8bc1de8bbdb6e343f132
[POWERPC] Find all of memory and feed all the heaps
This code walks the OF dev tree, finding end-of-memory and memory holes.
All memory beyond the hypervisor's RMA is added to domheap. (Previously
only memory upto 1st hole was used.) Finally, parts of setup.c have been
swept into memory.c as cleanup.
Based-on-patch-by: Dan Poff [EMAIL PROTECTED]
Signed-off-by: Jimi Xenidis [EMAIL PROTECTED]
---
xen/arch/powerpc/Makefile |1
xen/arch/powerpc/exceptions.h |3
xen/arch/powerpc/memory.c | 210 ++
xen/arch/powerpc/oftree.h |4
xen/arch/powerpc/setup.c | 118 ---
5 files changed, 219 insertions(+), 117 deletions(-)
diff -r 6eccd4911e6c -r f2527015891c xen/arch/powerpc/Makefile
--- a/xen/arch/powerpc/Makefile Tue Aug 22 11:17:09 2006 -0400
+++ b/xen/arch/powerpc/Makefile Tue Aug 22 17:20:58 2006 -0400
@@ -23,6 +23,7 @@ obj-y += iommu.o
obj-y += iommu.o
obj-y += irq.o
obj-y += mambo.o
+obj-y += memory.o
obj-y += mm.o
obj-y += mpic.o
obj-y += mpic_init.o
diff -r 6eccd4911e6c -r f2527015891c xen/arch/powerpc/exceptions.h
--- a/xen/arch/powerpc/exceptions.h Tue Aug 22 11:17:09 2006 -0400
+++ b/xen/arch/powerpc/exceptions.h Tue Aug 22 17:20:58 2006 -0400
@@ -51,7 +51,4 @@ extern char exception_vectors[];
extern char exception_vectors[];
extern char exception_vectors_end[];
extern int spin_start[];
-extern int firmware_image_start[0];
-extern int firmware_image_size[0];
-
#endif
diff -r 6eccd4911e6c -r f2527015891c xen/arch/powerpc/oftree.h
--- a/xen/arch/powerpc/oftree.h Tue Aug 22 11:17:09 2006 -0400
+++ b/xen/arch/powerpc/oftree.h Tue Aug 22 17:20:58 2006 -0400
@@ -20,9 +20,11 @@
#ifndef _OFTREE_H
#define _OFTREE_H
+#include xen/multiboot.h
extern ulong oftree;
extern ulong oftree_len;
+extern ulong oftree_end;
extern int ofd_dom0_fixup(
struct domain *d, ulong mem, start_info_t *si, ulong dst);
@@ -30,4 +32,6 @@ extern int firmware_image_start[0];
extern int firmware_image_start[0];
extern int firmware_image_size[0];
+extern void memory_init(module_t *mod, int mcount);
+
#endif /* #ifndef _OFTREE_H */
diff -r 6eccd4911e6c -r f2527015891c xen/arch/powerpc/setup.c
--- a/xen/arch/powerpc/setup.c Tue Aug 22 11:17:09 2006 -0400
+++ b/xen/arch/powerpc/setup.c Tue Aug 22 17:20:58 2006 -0400
@@ -43,9 +43,9 @@
#include asm/percpu.h
#include exceptions.h
#include of-devtree.h
+#include oftree.h
#define DEBUG
-unsigned long xenheap_phys_end;
/* opt_noht: If true, Hyperthreading is ignored. */
int opt_noht = 0;
@@ -221,24 +221,6 @@ void startup_cpu_idle_loop(void)
reset_stack_and_jump(idle_loop);
}
-static ulong free_xenheap(ulong start, ulong end)
-{
-start = ALIGN_UP(start, PAGE_SIZE);
-end = ALIGN_DOWN(end, PAGE_SIZE);
-
-printk(%s: 0x%lx - 0x%lx\n, __func__, start, end);
-
-if (oftree = end oftree = start) {
-printk(%s: Go around the devtree: 0x%lx - 0x%lx\n,
- __func__, oftree, oftree_end);
-init_xenheap_pages(start, ALIGN_DOWN(oftree, PAGE_SIZE));
-init_xenheap_pages(ALIGN_UP(oftree_end, PAGE_SIZE), end);
-} else {
-init_xenheap_pages(start, end);
-}
-return ALIGN_UP(end, PAGE_SIZE);
-}
-
static void init_parea(int cpuid)
{
/* Be careful not to shadow the global variable. */
@@ -290,15 +272,8 @@ static void __init __start_xen(multiboot
{
char *cmdline;
module_t *mod = (module_t *)((ulong)mbi-mods_addr);
-ulong heap_start;
-ulong eomem = 0;
-ulong heap_size = 0;
-ulong bytes = 0;
-ulong freemem;
ulong dom0_start, dom0_len;
ulong initrd_start, initrd_len;
-
-int i;
memcpy(0, exception_vectors, exception_vectors_end - exception_vectors);
synchronize_caches(0, exception_vectors_end - exception_vectors);
@@ -340,98 +315,13 @@ static void __init __start_xen(multiboot
mod[mbi-mods_count-1].mod_end = 0;
--mbi-mods_count;
-printk(Physical RAM map:\n);
-
-/* lets find out how much memory there is */
-while (bytes mbi-mmap_length) {
-u64 end;
-u64 addr;
-u64 size;
-
-memory_map_t *map = (memory_map_t *)((ulong)mbi-mmap_addr + bytes);
-addr = ((u64)map-base_addr_high 32) | (u64)map-base_addr_low;
-size = ((u64)map-length_high 32) | (u64)map-length_low;
-end = addr + size;
-
-printk( %016lx - %016lx (usable)\n, addr, end);
-
-if (addr eomem) {
-printk(found a hole skipping remainder of memory at:\n
-%016lx and beyond\n, addr);
-break;
-}
-if (end eomem) {
-eomem = end;
-}
-bytes += map-size + 4;
-}
-
-printk(System RAM: %luMB (%lukB)\n, eomem 20, eomem 10);
-
-/* top of
[XenPPC] RMA and Real memory
Currently when we create a domain we immediately allocate its RMA. Previously we allowed the xend tools to fail when allocating more memory. However, when the tools probe to see if there is enuf memory to allocate the expected failing one it goes after the balloon driver. specific example: RAM=256M RMA=64M Xen gets 64M Some small domheap allocations occur eating up about 5M (the page frame table mostly) Dom0 get 64M DomU creation allocates 64M for RMA Xend sees only 59M left and goes after the balloon driver. BUSTED! Anyway.. we need to get a handle on this... thoughts? -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] [XEND] abstract architecture-specific bits in image.py
Since this patch wasn't committed, the shadow2 changes created
conflicts. Here is the respin. Note that I have not tested with shadow2,
but as you can see below the math doesn't need to be so complicated.
Ewan, please apply or comment.
[XEND] abstract architecture-specific bits in image.py
- create arch.type (which evaluates to x86, ia64 or powerpc)
- create subclasses for x86 and ia64 HVM loaders
- rework findImageHandlerClass()
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff -r 5fc1fe790835 tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py Sat Aug 19 17:07:54 2006 +0100
+++ b/tools/python/xen/xend/XendDomainInfo.py Tue Aug 22 16:11:57 2006 -0500
@@ -30,7 +30,6 @@ import time
import time
import threading
import os
-import math
import xen.lowlevel.xc
from xen.util import asserts
@@ -1280,34 +1279,27 @@ class XendDomainInfo:
for v in range(0, self.info['max_vcpu_id']+1):
xc.vcpu_setaffinity(self.domid, v, self.info['cpus'])
-# set domain maxmem in KiB
-xc.domain_setmaxmem(self.domid, self.info['maxmem'] * 1024)
-
-m = self.image.getDomainMemory(self.info['memory'] * 1024)
+# set memory limit
+maxmem = self.image.getRequiredMemory(self.info['maxmem'] * 1024)
+xc.domain_setmaxmem(self.domid, maxmem)
+
+mem_kb = self.image.getRequiredMemory(self.info['memory'] * 1024)
# get the domain's shadow memory requirement
-sm = int(math.ceil(self.image.getDomainShadowMemory(m) / 1024.0))
-if self.info['shadow_memory'] sm:
-sm = self.info['shadow_memory']
+shadow_kb = self.image.getRequiredShadowMemory(mem_kb)
+shadow_kb_req = self.info['shadow_memory'] * 1024
+if shadow_kb_req shadow_kb:
+shadow_kb = shadow_kb_req
# Make sure there's enough RAM available for the domain
-balloon.free(m + sm * 1024)
+balloon.free(mem_kb + shadow_kb)
# Set up the shadow memory
-sm = xc.shadow_mem_control(self.domid, mb=sm)
-self.info['shadow_memory'] = sm
-
-init_reservation = self.info['memory'] * 1024
-if os.uname()[4] in ('ia64', 'ppc64'):
-# Workaround for architectures that don't yet support
-# ballooning.
-init_reservation = m
-# Following line from [EMAIL PROTECTED]
-# Needed for IA64 until supports ballooning -- okay for PPC64?
-xc.domain_setmaxmem(self.domid, m)
-
-xc.domain_memory_increase_reservation(self.domid, init_reservation,
- 0, 0)
+shadow_cur = xc.shadow_mem_control(self.domid, shadow_kb * 1024)
+self.info['shadow_memory'] = shadow_cur
+
+# initial memory allocation
+xc.domain_memory_increase_reservation(self.domid, mem_kb, 0, 0)
self.createChannels()
diff -r 5fc1fe790835 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.pySat Aug 19 17:07:54 2006 +0100
+++ b/tools/python/xen/xend/image.pyTue Aug 22 15:30:36 2006 -0500
@@ -27,6 +27,8 @@ from xen.xend.XendLogging import log
from xen.xend.XendLogging import log
from xen.xend.server.netif import randomMAC
from xen.xend.xenstore.xswatch import xswatch
+from xen.xend import arch
+from xen.xend import FlatDeviceTree
xc = xen.lowlevel.xc.xc()
@@ -141,19 +143,10 @@ class ImageHandler:
raise VmError('Building domain failed: ostype=%s dom=%d err=%s'
% (self.ostype, self.vm.getDomid(), str(result)))
-
-def getDomainMemory(self, mem_kb):
-@return The memory required, in KiB, by the domain to store the
-given amount, also in KiB.
-if os.uname()[4] != 'ia64':
-# A little extra because auto-ballooning is broken w.r.t. HVM
-# guests. Also, slack is necessary for live migration since that
-# uses shadow page tables.
-if 'hvm' in xc.xeninfo()['xen_caps']:
-mem_kb += 4*1024;
+def getRequiredMemory(self, mem_kb):
return mem_kb
-def getDomainShadowMemory(self, mem_kb):
+def getRequiredShadowMemory(self, mem_kb):
@return The minimum shadow memory required, in KiB, for a domain
with mem_kb KiB of RAM.
# PV domains don't need any shadow memory
@@ -197,9 +190,39 @@ class LinuxImageHandler(ImageHandler):
ramdisk= self.ramdisk,
features = self.vm.getFeatures())
+class PPC_LinuxImageHandler(LinuxImageHandler):
+
+ostype = linux
+
+def configure(self, imageConfig, deviceConfig):
+LinuxImageHandler.configure(self, imageConfig, deviceConfig)
+self.imageConfig = imageConfig
+
+def
[XenPPC] [xenppc-unstable] [XEND][POWERPC] fix typo
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Node ID 5ec3af32d347a058f6939fb9b13c0cb2d6247566
# Parent e06e2cca9f39d56344ec96b90ad4a2405b247996
[XEND][POWERPC] fix typo
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
tools/python/xen/xend/FlatDeviceTree.py |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -r e06e2cca9f39 -r 5ec3af32d347 tools/python/xen/xend/FlatDeviceTree.py
--- a/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 17:26:36 2006 -0400
+++ b/tools/python/xen/xend/FlatDeviceTree.py Tue Aug 22 16:32:54 2006 -0500
@@ -293,7 +293,7 @@ def build(imghandler):
# identical...
cpu0 = None
def _nolinuxprops(fullpath):
-return not os.path.basename(fullpath).startswith('linux,'):
+return not os.path.basename(fullpath).startswith('linux,')
for i in range(imghandler.vm.getVCpuCount()):
cpu = cpus.addnode('PowerPC,[EMAIL PROTECTED]')
_copytree(cpu, 'cpus/PowerPC,[EMAIL PROTECTED]', _nolinuxprops)
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [xenppc-unstable] [XEND][POWERPC] correct shadow2 merge conflict
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Node ID 8fa42dd4c92a1e3c27e20fc5225edaa49bfb4972
# Parent 5ec3af32d347a058f6939fb9b13c0cb2d6247566
[XEND][POWERPC] correct shadow2 merge conflict
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
---
tools/python/xen/xend/XendDomainInfo.py | 45
tools/python/xen/xend/image.py | 41 +++--
2 files changed, 27 insertions(+), 59 deletions(-)
diff -r 5ec3af32d347 -r 8fa42dd4c92a tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py Tue Aug 22 16:32:54 2006 -0500
+++ b/tools/python/xen/xend/XendDomainInfo.py Tue Aug 22 16:35:07 2006 -0500
@@ -30,7 +30,6 @@ import time
import time
import threading
import os
-import math
import xen.lowlevel.xc
from xen.util import asserts
@@ -1280,37 +1279,27 @@ class XendDomainInfo:
for v in range(0, self.info['max_vcpu_id']+1):
xc.vcpu_setaffinity(self.domid, v, self.info['cpus'])
-# set domain maxmem in KiB
-xc.domain_setmaxmem(self.domid, self.info['maxmem'] * 1024)
-
-m = self.image.getDomainMemory(self.info['memory'] * 1024)
+# set memory limit
+maxmem = self.image.getRequiredMemory(self.info['maxmem'] * 1024)
+xc.domain_setmaxmem(self.domid, maxmem)
+
+mem_kb = self.image.getRequiredMemory(self.info['memory'] * 1024)
# get the domain's shadow memory requirement
-sm = int(math.ceil(self.image.getDomainShadowMemory(m) / 1024.0))
-if self.info['shadow_memory'] sm:
-sm = self.info['shadow_memory']
+shadow_kb = self.image.getRequiredShadowMemory(mem_kb)
+shadow_kb_req = self.info['shadow_memory'] * 1024
+if shadow_kb_req shadow_kb:
+shadow_kb = shadow_kb_req
# Make sure there's enough RAM available for the domain
-balloon.free(m + sm * 1024)
-
-if os.uname()[4] in ('ppc64'):
-self.info['shadow_memory'] = 0
-else:
-# Set up the shadow memory
-sm = xc.shadow_mem_control(self.domid, mb=sm)
-self.info['shadow_memory'] = sm
-
-init_reservation = self.info['memory'] * 1024
-if os.uname()[4] in ('ia64', 'ppc64'):
-# Workaround for architectures that don't yet support
-# ballooning.
-init_reservation = m
-# Following line from [EMAIL PROTECTED]
-# Needed for IA64 until supports ballooning -- okay for PPC64?
-xc.domain_setmaxmem(self.domid, m)
-
-xc.domain_memory_increase_reservation(self.domid, init_reservation,
- 0, 0)
+balloon.free(mem_kb + shadow_kb)
+
+# Set up the shadow memory
+shadow_cur = xc.shadow_mem_control(self.domid, shadow_kb * 1024)
+self.info['shadow_memory'] = shadow_cur
+
+# initial memory allocation
+xc.domain_memory_increase_reservation(self.domid, mem_kb, 0, 0)
self.createChannels()
diff -r 5ec3af32d347 -r 8fa42dd4c92a tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.pyTue Aug 22 16:32:54 2006 -0500
+++ b/tools/python/xen/xend/image.pyTue Aug 22 16:35:07 2006 -0500
@@ -146,7 +146,7 @@ class ImageHandler:
def getRequiredMemory(self, mem_kb):
return mem_kb
-def getDomainShadowMemory(self, mem_kb):
+def getRequiredShadowMemory(self, mem_kb):
@return The minimum shadow memory required, in KiB, for a domain
with mem_kb KiB of RAM.
# PV domains don't need any shadow memory
@@ -197,10 +197,6 @@ class PPC_LinuxImageHandler(LinuxImageHa
def configure(self, imageConfig, deviceConfig):
LinuxImageHandler.configure(self, imageConfig, deviceConfig)
self.imageConfig = imageConfig
-
-def getDomainMemory(self, mem_kb):
-@see ImageHandler.getDomainMemory
-return mem_kb
def buildDomain(self):
store_evtchn = self.vm.getStorePort()
@@ -382,32 +378,6 @@ class HVMImageHandler(ImageHandler):
os.waitpid(self.pid, 0)
self.pid = 0
-def getDomainMemory(self, mem_kb):
-@see ImageHandler.getDomainMemory
-if os.uname()[4] == 'ia64':
-page_kb = 16
-# ROM size for guest firmware, ioreq page and xenstore page
-extra_pages = 1024 + 2
-else:
-page_kb = 4
-# This was derived emperically:
-# 2.4 MB overhead per 1024 MB RAM + 8 MB constant
-# + 4 to avoid low-memory condition
-extra_mb = (2.4/1024) * (mem_kb/1024.0) + 12;
-extra_pages = int( math.ceil( extra_mb*1024 / page_kb ))
-return mem_kb + extra_pages * page_kb
-
-
