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 :
If we agree on using xencomm we will have to work with xen/ppc people
in order not to duplicate the code.
Le Vendredi 18 Août 2006 23:21, Hollis Blanchard a écrit :
On Fri, 2006-08-18 at 18:02 +0200, Tristan Gingold wrote:
these are the patches to port xencomm on ia64. This is just an RFC. I
have to clean-up the code so that it could be shared between ia64 and
ppc.
Great! Your patches were
Le Vendredi 18 Août 2006 23:21, Hollis Blanchard a écrit :
On Fri, 2006-08-18 at 18:02 +0200, Tristan Gingold wrote:
[...]
I have also fixed a few bugs in guest_access.h
Do you think you could split those out as a diff to
xen/include/asm-powerpc/guest_access.h, to be applied before we move
On 21/8/06 9:03 am, Tristan Gingold [EMAIL PROTECTED] wrote:
xencomm is the ppc infrastructure to do hypercalls with guest physical
addresses instead of virtual address.
Because ia64 should also use physicall address, I think it's better to re-use
the ppc code and to put into common
On 21/8/06 10:20 am, Tristan Gingold [EMAIL PROTECTED] wrote:
Fine in principle. Specific comments:
* powerpc should be cleaned up at the same time to use the common
infrastructure. I don't want duplicated code hanging around in arch/powerpc
I have attached a blindly-made patch again
On Aug 21, 2006, at 12:07 AM, Olof Johansson wrote:
On Wed, Aug 09, 2006 at 09:05:24AM -0400, Jimi Xenidis wrote:
We intend to include these in the OpenPAPR :-P
Yet another PAPR!?
hmm..
no the same one power.org blessed, the plan is to have Xen bindings
and more :)
why is 1100+ pages
On Aug 21, 2006, at 3:47 AM, Tristan Gingold wrote:
Le Vendredi 18 Août 2006 23:21, Hollis Blanchard a écrit :
On Fri, 2006-08-18 at 18:02 +0200, Tristan Gingold wrote:
[...]
I have also fixed a few bugs in guest_access.h
Do you think you could split those out as a diff to
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID e354171fa00b92cf3715a808069608bfa40780a0
# Parent dbe9249ba61b0d616f3e43ee54fea83d635285c9
[POWEPRC] missing shadow skeleton
---
xen/arch/powerpc/shadow.c | 36
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID 792d2d89749a6ba3fbac3973cf0c893db5f76c7f
# Parent e354171fa00b92cf3715a808069608bfa40780a0
[POWEPRC] copyright
---
xen/arch/powerpc/shadow.c | 20
1 files changed, 20 insertions(+)
diff -r e354171fa00b
Le Lundi 21 Août 2006 13:13, Jimi Xenidis a écrit :
On Aug 21, 2006, at 3:47 AM, Tristan Gingold wrote:
Le Vendredi 18 Août 2006 23:21, Hollis Blanchard a écrit :
On Fri, 2006-08-18 at 18:02 +0200, Tristan Gingold wrote:
[...]
I have also fixed a few bugs in guest_access.h
Do you
On Aug 20, 2006, at 9:38 PM, Maria Butrico wrote:
I get lots of shadow errors. patch forthcoming. Where is shadow.c?
DAMN!
Sorry, keep forgetting hg add
pushed and thanks for peeking at my dir and posing the file :-)
-JX
___
Xen-ppc-devel
I get the same error with xm (I updated last night).
[2006-08-21 12:08:13 xend.XendDomainInfo 5985] DEBUG
(XendDomainInfo:189) XendDomainInfo.create(['vm', ['name', 'J9-Lib-OS'],
['memory', 32], ['on_crash', 'destroy'], ['vcpus', 1], ['image',
['linux', ['kernel', '/home/j9/bin/j9')
poff wrote:
We have xen running on an Intel blade with SuSE10; may be helpful to view scripts
logs...
Thank you Don. Kawachiya-san also has mini-os running on x86 and I have
his scripts. They work for him, but not for me.
___
Xen-ppc-devel
Jimi Xenidis wrote:
On Aug 19, 2006, at 4:38 PM, Maria Butrico wrote:
These are from xend-debug.log. What do they indicate? Are they fatal?
/home/j9/xen-tools/etc/xen/scripts/xen-network-common.sh: line 130:
brctl: command not found
/usr/lib/python2.4/xmllib.py:9: DeprecationWarning: The
I am not sure what this means. The code from the hg repository still
does not compile.
Jimi Xenidis wrote:
On Aug 20, 2006, at 9:58 PM, Maria Butrico wrote:
Summary: Allow compilation under gcc4
diff -r dbe9249ba61b xen/arch/powerpc/oftree.h
I covered the current.h issues with dan,
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID 326e6736d92bf8079ff360292aeeaef3b2958bb4
# Parent 792d2d89749a6ba3fbac3973cf0c893db5f76c7f
[POWERPC] more -Wshadow issues with gcc4
---
xen/arch/powerpc/ofd_fixup.c |4 ++--
xen/arch/powerpc/oftree.h|2 +-
2 files
wow, thats a little unexpected, what version of gcc is that?
anyway, does the following patch solve the issue?
-JX
diff -r dbe9249ba61b xen/include/asm-powerpc/current.h
--- a/xen/include/asm-powerpc/current.h Sun Aug 20 13:28:45 2006 -0400
+++ b/xen/include/asm-powerpc/current.h
Looks good Amos. :)
On Sat, 2006-08-19 at 02:47 -0400, Amos Waterland wrote:
diff -r 539a1e666982 xen/arch/powerpc/powerpc64/exceptions.S
--- a/xen/arch/powerpc/powerpc64/exceptions.S Fri Aug 18 14:07:50
2006 -0400
+++ b/xen/arch/powerpc/powerpc64/exceptions.S Fri Aug 18 21:06:13
2006
I think maria reported the oftree.h issue, this morning.
I pushed that solution, please try that.
-JX
On Aug 21, 2006, at 11:31 AM, poff wrote:
wow, thats a little unexpected, what version of gcc is that?
anyway, does the following patch solve the issue?
-JX
diff -r dbe9249ba61b
Currently people monitor xen-bugs and pull out ones they can deal with.
The traffic level isn't particularly high and it wouldn't be too hard to
filter on ones without PPC in the message body.
James
-Original Message-
From: Hollis Blanchard [mailto:[EMAIL PROTECTED]
Sent: 21 August
Ok.. The PPC team are finally going whole hog on the VIO stuff and
going after net front/back.
I'm looking at linux: network_alloc_rx_buffers() which allocates a
bunch of skbuf pages and eventually calls XENMEM_decrease_reservation
to remove them from the domain.
We use large pages, and in
We use large pages, and in fact we are forced to a special area to
handle real mode exceptions called an RMA.
Consider it a permanent large page (64M) that is used for real mode,
this is our minimum memory.
In order to decrease a reservation that mean that memory must be
greater than this
On Aug 21, 2006, at 1:11 PM, Ian Pratt wrote:
We use large pages, and in fact we are forced to a special area to
handle real mode exceptions called an RMA.
Consider it a permanent large page (64M) that is used for real mode,
this is our minimum memory.
In order to decrease a reservation that
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.
--
Hollis Blanchard
On Sun, 2006-08-20 at 17:12 +, Xen patchbot-xenppc-unstable wrote:
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID 6b9124f9d89d58eb81847813dc0043ba3896b919
# Parent b1fd0275383baa78830f70c8b15d7ac0f3510f4d
[TOOLS] add missing python PPC_ method
Signed-off-by: Jimi
On Mon, 2006-08-21 at 14:43 -0500, Hollis Blanchard wrote:
diff -r b1fd0275383b -r 6b9124f9d89d tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.pySun Aug 20 13:00:31 2006 -0400
+++ b/tools/python/xen/xend/image.pySun Aug 20 13:02:16 2006 -0400
@@ -197,6
On Sun, 2006-08-20 at 13:28 -0400, Jimi Xenidis wrote:
Hollis, I'm sure you have a better way to do this in the TCL.
I'll be adding some shadow ops to the hypervisor, mainly to make sure
everyone knows that it is disabled, but this TCL was still problematic.
-JX
On Aug 20, 2006, at 1:12
On Aug 21, 2006, at 4:00 PM, Hollis Blanchard wrote:
On Sun, 2006-08-20 at 13:28 -0400, Jimi Xenidis wrote:
Hollis, I'm sure you have a better way to do this in the TCL.
I'll be adding some shadow ops to the hypervisor, mainly to make sure
everyone knows that it is disabled, but this TCL was
Yes, exactly. And since ImageHandler has this:
def getDomainShadowMemory(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
return 0
PPC_LinuxImageHandler derives
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.
Signed-off-by: Maria Butrico [EMAIL PROTECTED]
diff -r 326e6736d92b
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
31 matches
Mail list logo
