[XenPPC] Re: [Xen-devel] Timeline for migrating to newer Linux kernels?

2007-01-09 Thread Jimi Xenidis
On Mon, Jan 01, 2007 at 04:44:30PM +, Keir Fraser wrote: On 1/1/07 12:21 am, "Rik van Riel" <[EMAIL PROTECTED]> wrote: XenSource has usually been less than useful when it comes to tracking the upstream kernel. I suspect they'll be obsoleted by KVM and/or lhype at some point in the future

Re: [XenPPC] [PATCH] Remove invalid optimization

2007-01-09 Thread Jerone Young
Sorry I sent the wrong patch file. Correct one is attached. On Tue, 2007-01-09 at 15:12 -0600, Jerone Young wrote: > This patch removes an invalid optimization that works great if you are a > kernel address (which is contiguous), but if you are module then you > have a kernel address but you are n

[XenPPC] [PATCH] Remove invalid optimization

2007-01-09 Thread Jerone Young
This patch removes an invalid optimization that works great if you are a kernel address (which is contiguous), but if you are module then you have a kernel address but you are not contiguous. So this check is invalid. diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/xencomm.c --- a/arch/powerpc/plat

Re: [XenPPC] [PATCH]fix xencomm_copy_{from, to}_guest.

2007-01-09 Thread Jerone Young
Keir, can you commit this patch to the tree. It has been tested and does not appear to cause any issues. Signed-off-by: Jerone Young <[EMAIL PROTECTED]> On Fri, 2007-01-05 at 12:19 +0900, Isaku Yamahata wrote: > fix xencomm_copy_{from, to}_guest. > It should not call paddr_to_maddr() with invali

Re: [XenPPC] [patch] multiboot2 support

2007-01-09 Thread Jimi Xenidis
On Jan 9, 2007, at 12:34 PM, Segher Boessenkool wrote: Wait a minute, doesn't systemsim has a passthrough call for memmove? If we should wire that up then this won't impact performance at all. We were/are trying to eliminate all simulator specific passthrus in the Xen core code. That so

Re: [XenPPC] [patch] multiboot2 support

2007-01-09 Thread Segher Boessenkool
Wait a minute, doesn't systemsim has a passthrough call for memmove? If we should wire that up then this won't impact performance at all. We were/are trying to eliminate all simulator specific passthrus in the Xen core code. That sounds rather counterproductive. What's wrong with having som

Re: [XenPPC] [patch] multiboot2 support

2007-01-09 Thread Jimi Xenidis
On Jan 9, 2007, at 12:09 PM, Hollis Blanchard wrote: On Thu, 2007-01-04 at 15:56 -0500, Jimi Xenidis wrote: We did a lot of work here so that stuff could be placed anywhere. I admit it was not pretty but I'd expect this patch to replace/improve not remove. The memmove below means this lo

Re: [XenPPC] [PATCH] Move lots of memory logic earlier

2007-01-09 Thread Jimi Xenidis
On Jan 9, 2007, at 11:24 AM, Hollis Blanchard wrote: On Mon, 2007-01-08 at 18:38 -0500, Jimi Xenidis wrote: Removing our custom allocator is important to simplify the upcoming multiboot2 conversion. how? We have currently have three page allocators. The first is PPC- specific, and

Re: [XenPPC] [patch] multiboot2 support

2007-01-09 Thread Hollis Blanchard
On Thu, 2007-01-04 at 15:56 -0500, Jimi Xenidis wrote: > > >> We did a lot of work here so that stuff could be placed anywhere. I > >> admit it was not pretty but I'd expect this patch to > replace/improve > >> not remove. > > > > The memmove below means this logic is unnecessary. > > I'd prefer

Re: [XenPPC] [PATCH] Move lots of memory logic earlier

2007-01-09 Thread Hollis Blanchard
On Mon, 2007-01-08 at 18:38 -0500, Jimi Xenidis wrote: > > Removing our custom allocator is important to simplify the upcoming > > multiboot2 conversion. > > how? We have currently have three page allocators. The first is PPC-specific, and it includes the Xen image, RTAS, and our copy of the