Re: [XenPPC] [PATCH] Move lots of memory logic earlier
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 Open Firmware
device tree. It's also limited to 32 MB, and that makes some of the code
rather hackful (particularly boot_of_alloc_init() and
boot_of_mem_init()).
Then we need to populate the common boot allocator. Right now this is
being done with ad-hoc communication between boot_of.c and memory.c via
a variety of global variables. We make lots of assumptions about the
location of those reserved areas. Since those areas can be placed
arbitrarily (like by a multiboot loader, for example), those assumptions
need to go. So instead we should use the PPC allocator bitmap to
populate the common allocator bitmap, and avoid all these globals.
Except we can't just copy it, because the second bitmap itself is not
present in the first bitmap. We also need to invent an interface to
access the early bitmap, or make it global, and don't you think we
already have too many globals in this area? So now the copy needs to
look something like this:
i = 0;
while (1) {
// here's the accessor we've invented:
i = boot_of_get_next_available(i, base, len);
if (i == -1)
break;
if (base, len) overlaps with (bitmap_addr, bitmap_len)
mangle (base, len) somehow
init_boot_pages(base, len);
}
If you take a step back, you might ask yourself why we have a bitmap
that's just being copied into another bitmap, when we could have used
the second bitmap all along? So that's what this patch does. In fact,
despite being more flexible than the current code (e.g. it does not
require the init_boot_allocator() to be below _start), this patch
removes more code than it adds.
- We also handle arbitrary-sized properties now, instead of
probably-large-enough fixed-sized buffers.
this is fine by me, I'm a big fan of alloca()!
However, you use:
proplen = of_getprop(child, string, NULL, 0);
when
proplen = of_getproplen(child, string);
Is sufficient and defined and used already in this file.
Great, will use that.
- This will also be needed to support non-Open Firmware systems
(though the
firmware-specific interface was not the focus of this patch).
But what is there is designed with non-OF in mind.
IMHO this is a step backwards.
rtas_base has no place in a firmware-agnostic memory.c, so I think
you'd agree there are at least some rough edges remaining?
I'll think about how to adapt this code to take into account firmware
that passes a flattened tree. In this patch, most of the new code would
need to be duplicated to call ofd_ routines instead of of_ routines
(a very poorly-named distinction IMHO).
--
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] multiboot2 support
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 some logic over blind moves of several megabytes (3-16), this will kill simulators. 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. -- 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] multiboot2 support
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 logic is unnecessary. I'd prefer some logic over blind moves of several megabytes (3-16), this will kill simulators. 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. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [patch] multiboot2 support
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 sounds rather counterproductive. What's wrong with having some minimal passthroughs? They help performance a *lot*, it's quite painful to run without. Of course, a command line option to disable it would be nice. There are currently only 3 large copies in xen, dom0-kernel, dom0- initrd (optional), and dom0-devtree after that the passthru gains us very little since the passthru is unavailable to the domain since the passthru requires machine addresses. Thing is in fast mode systemsim is good enuff, right now the biggest simulation problem is uncompressing kernels, and even that is not so bad. We have only one required on_sim() call and that is because systemsim does not provide a DART simulation (which means that any IO is unusable). Further more, I'm hoping to see more simulators each having more accelerators further complicating the passthru logic. I'd rather simply push back to the simulators. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH]fix xencomm_copy_{from, to}_guest.
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 invalid address.
Originally this issue was found in xen/ia64 xencomm code and
in fact I didn't test this patch because currently ia64 xencomm forked
from common code. They should be consolidated somehow.
--
yamahata
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1167966417 -32400
# Node ID 25cdcc5f21f8147371aed5fb8f56d93479df0ca8
# Parent 338ceb7b1f0993bf9735c0c1c5d21e39c381cf2f
fix xencomm_copy_{from, to}_guest.
It should not call paddr_to_maddr() with invalid address.
PATCHNAME: fix_xencomm_copy_tofrom_guest
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 338ceb7b1f09 -r 25cdcc5f21f8 xen/common/xencomm.c
--- a/xen/common/xencomm.c Thu Jan 04 10:58:01 2007 +
+++ b/xen/common/xencomm.c Fri Jan 05 12:06:57 2007 +0900
@@ -119,7 +119,7 @@ xencomm_copy_from_guest(void *to, const
chunksz -= chunk_skip;
skip -= chunk_skip;
-if (skip == 0) {
+if (skip == 0 chunksz 0) {
unsigned long src_maddr;
unsigned long dest = (unsigned long)to + to_pos;
unsigned int bytes = min(chunksz, n - to_pos);
@@ -225,7 +225,7 @@ xencomm_copy_to_guest(void *to, const vo
chunksz -= chunk_skip;
skip -= chunk_skip;
-if (skip == 0) {
+if (skip == 0 chunksz 0) {
unsigned long dest_maddr;
unsigned long source = (unsigned long)from + from_pos;
unsigned int bytes = min(chunksz, n - from_pos);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Remove invalid optimization
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/platforms/xen/xencomm.c Tue Dec 19 09:22:37 2006 -0500 +++ b/arch/powerpc/platforms/xen/xencomm.c Tue Jan 09 14:50:55 2007 -0600 @@ -36,9 +36,6 @@ unsigned long xencomm_vtop(unsigned long if (vaddr == 0) return 0; - if (is_kernel_addr(vaddr)) - return __pa(vaddr); - /* XXX double-check (lack of) locking */ vma = find_extend_vma(current-mm, vaddr); BUG_ON(!vma); ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Timeline for migrating to newer Linux kernels?
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, because those will just be there in the upstream kernel while Xen won't. If XenSource has any intention of having Xen stay relevant in the future, they'll want to seriously pursue an upstream merge of their code. There are ongoing efforts from (at least) XenSource, Novell, Red Hat and IBM to merge Xen support into upstream Linux. The paravirt_ops infrastructure is already merged for 2.6.20 and we will hopefully see implementations of the new interface, including Xen, merged for 2.6.21. As for the Linux sparse tree in xen-unstable, it will be upgraded and moved to a separate repository before 3.0.5. With the guest kernel interfaces having been stable for some time, it makes lots of sense to separate hypervisor development and its release cycle from that of guest kernels. Sorry for the disconnected reply, but is there a time line for this? how can other help? The xen-ppc team is lagging behind both kernel.org and sen-unstable and we've lost all hope of regaining a common root. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
