[XenPPC] FYI: PowerPC Xen port removed
http://lists.xensource.com/archives/html/xen-changelog/2008-05/msg00091.html -- 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] XEN on e500/Book E
On Mon, 2008-03-24 at 16:50 -0700, Rahul Kulkarni wrote: Are there any plans for porting XEN to the e500/Book E architecture specifically MPC 85xx processors? I personally don't have plans to continue Xen development, but I can't speak for anybody else. However, some very experimental work has been done for e500 with KVM. There's been some discussion on kvm-ppc-devel (http://marc.info/?l=kvm-ppc-devel) . Can I ask what your interest is? Are you a developer or just looking to use it? If you had virtualization on e500 today, how would you use 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] Porting Hypervisor to another OS, and using Linux on PowerPC 750
On Tue, 2007-10-16 at 10:20 +0200, Claes Lilliesköld wrote: Hello, I'm looking for a way to run Linux on top on an RTOS on a PowerPC 750 based system. To achieve this, at least the following need to be done: 1. Port the hypervisor interface to the RTOS. 2. Adapt the XEN Linux to be able to run on PowerPC 750. The current PowerPC support is only for PowerPC 970 from what I understand. Correct. Also note that Xen's PowerPC support depends on the hardware virtualization extensions found in server architecture PowerPC such as 970. The 750 lacks these features. I'd be grateful if you could comment on if this is possible, and how it should be done. I don't know of anybody doing an open source hypervisor for 750. I think there are a few commercial solutions if you want to deploy something today. However, there are a few people looking at KVM on embedded PowerPC, so I'm CCing kvm-ppc-devel. So far we've been thinking mostly about Book E (440 and e500), but if you're interested in developing support for 750 that would be a good place to discuss. Currently we have an unmodified 440 Linux kernel booting as a guest, but userspace doesn't work yet. I think KVM makes more sense for embedded PowerPC because we can reuse Linux's existing support for the huge variety of cores/chips/boards. By the way, what RTOS are you using, and what sort of real-time and MMU requirements do you have? -- 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] fast_resume instead of full_resume after hdec_out
Sounds reasonable to me. When I get a chance I'll try it out; I need to do a little work to track upstream Xen changes anyways. I don't think I'll have time in the next two weeks though (just FYI)... On Tue, 2007-09-11 at 04:22 +, HYEONSEUNG JANG wrote: In handling hdec exception, non-volatile registers are saved because context_switch() may be called in the do_softirq(). The fact that we reach to 'hdec_out' means that there has been no context_switch() called. But currently 'fast_resume' is called after 'hdec_out' I think there seems to be no reason to restore non-volatiles at this point. Becasue MSR_EE is alwyas 0, 'fast_resume' will be enough like the following. It seems to work well in our HW. Please give me comments or something. - Hyeonseung Jang. diff -r 9071521d4864 xen/arch/powerpc/powerpc64/exceptions.S --- a/xen/arch/powerpc/powerpc64/exceptions.S Fri Sep 07 11:39:10 2007 +0100 +++ b/xen/arch/powerpc/powerpc64/exceptions.S Tue Sep 11 11:38:25 2007 +0900 @@ -514,6 +514,7 @@ hdec_out: hdec_out: addi r1, r1, STACK_FRAME_OVERHEAD /* restore stack to cpu_user_regs */ LOAD_GPRS r14, r15, r1 /* we clobbered r14/r15 in the loop */ +b fast_resume /* r1 points to the to-be-restored cpu_user_regs. These could be mid-hypervisor * stack (returning into elsewhere in Xen) or at the top of the stack ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel -- 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: [Xen-devel] Re: [XenPPC] [PATCH 2/7] xencomm take 3: xen side preparetion for consolidation.
On Wed, 2007-08-15 at 12:46 +0900, Isaku Yamahata wrote: On Tue, Aug 14, 2007 at 09:48:00AM -0500, Hollis Blanchard wrote: However, there are a few places below where you call memcpy() without checking the result of xencomm_maddr_to_vaddr(). Actually, I see the same issue in the original code in a few places... We should be very very careful here, since a guest passing a bad paddr could result in Xen overwriting 0x0. Thank you for comments. The next patch (3/7) addresses those issues. i.e. checking guest supplied values, avoiding races. I intentionally kept this patch(2/7) as small as possible leaving them to the next patch (3/7). Ah, great. Since we can work around the populate physmap issue, it's ok for me to drop multi page support. But we need the next patch or something similar. If you dislike the implementation, I'm willing to refine it. Please suggest. Patch 3 looks fine to me. I would like to give it a boot test first though, and unfortunately I won't be able to do that today. I'll add my signed-off line tomorrow after I've tried 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: [Xen-devel] Re: [XenPPC] [PATCH 1/4] xencomm take 2: xen side varisous fixes and preparation for consolidation
On Tue, 2007-08-14 at 10:39 +0900, Isaku Yamahata wrote: BTW although I know you need to test it before ack, how do you like other patches (2/4 and 3/4)? I'd like to finish linux side xencomm consolidation at first so that I can focus on xen side xencomm. BTW, I've been looking at the Xen patches first because those can go in before the Linux patches. The opposite of course isn't true... -- 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 2/7] xencomm take 3: xen side preparetion for consolidation.
This is definitely needed and I apologize for my maddr/vaddr confusion
in the first place.
However, there are a few places below where you call memcpy() without
checking the result of xencomm_maddr_to_vaddr(). Actually, I see the
same issue in the original code in a few places... We should be very
very careful here, since a guest passing a bad paddr could result in Xen
overwriting 0x0.
On Tue, 2007-08-14 at 18:50 +0900, Isaku Yamahata wrote:
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1187077583 -32400
# Node ID 4dbbedee6bb8d594287940470a61b8c0c56daf9c
# Parent 68867379b785a9a6fd37ca75be64fa7b5e3b8a2b
[xen, xencomm] preparetion for xencomm consolidation.
Xen/powerpc runs in real mode so that it uses maddr interchangably with
vaddr.
But it isn't the case in xen/ia64. It is necessary to convert maddr to vaddr
to access the page. maddr_to_virt() doesn't convert on powerpc, so it should
work on both archtechture.
PATCHNAME: xencomm_consolidation_maddr_vaddr
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 68867379b785 -r 4dbbedee6bb8 xen/common/xencomm.c
--- a/xen/common/xencomm.cTue Aug 14 16:44:42 2007 +0900
+++ b/xen/common/xencomm.cTue Aug 14 16:46:23 2007 +0900
@@ -34,6 +34,15 @@ static int xencomm_debug = 1; /* extreme
#define xencomm_debug 0
#endif
+static void*
+xencomm_maddr_to_vaddr(unsigned long maddr)
+{
+if (maddr == 0)
+return NULL;
+
+return maddr_to_virt(maddr);
+}
+
static unsigned long
xencomm_inline_from_guest(void *to, const void *from, unsigned int n,
unsigned int skip)
@@ -54,7 +63,7 @@ xencomm_inline_from_guest(void *to, cons
src_maddr = paddr_to_maddr(src_paddr);
if (xencomm_debug)
printk(%lx[%d] - %lx\n, src_maddr, bytes, (unsigned long)to);
-memcpy(to, (void *)src_maddr, bytes);
+memcpy(to, maddr_to_virt(src_maddr), bytes);
src_paddr += bytes;
to += bytes;
n -= bytes;
@@ -89,7 +98,8 @@ xencomm_copy_from_guest(void *to, const
return xencomm_inline_from_guest(to, from, n, skip);
/* first we need to access the descriptor */
-desc = (struct xencomm_desc *)paddr_to_maddr((unsigned long)from);
+desc = (struct xencomm_desc *)
+xencomm_maddr_to_vaddr(paddr_to_maddr((unsigned long)from));
if (desc == NULL)
return n;
@@ -130,7 +140,7 @@ xencomm_copy_from_guest(void *to, const
if (xencomm_debug)
printk(%lx[%d] - %lx\n, src_maddr, bytes, dest);
-memcpy((void *)dest, (void *)src_maddr, bytes);
+memcpy((void *)dest, maddr_to_virt(src_maddr), bytes);
from_pos += bytes;
to_pos += bytes;
}
@@ -161,7 +171,7 @@ xencomm_inline_to_guest(void *to, const
dest_maddr = paddr_to_maddr(dest_paddr);
if (xencomm_debug)
printk(%lx[%d] - %lx\n, (unsigned long)from, bytes,
dest_maddr);
-memcpy((void *)dest_maddr, (void *)from, bytes);
+memcpy(maddr_to_virt(dest_maddr), (void *)from, bytes);
dest_paddr += bytes;
from += bytes;
n -= bytes;
@@ -196,7 +206,8 @@ xencomm_copy_to_guest(void *to, const vo
return xencomm_inline_to_guest(to, from, n, skip);
/* first we need to access the descriptor */
-desc = (struct xencomm_desc *)paddr_to_maddr((unsigned long)to);
+desc = (struct xencomm_desc *)
+xencomm_maddr_to_vaddr(paddr_to_maddr((unsigned long)to));
if (desc == NULL)
return n;
@@ -236,7 +247,7 @@ xencomm_copy_to_guest(void *to, const vo
if (xencomm_debug)
printk(%lx[%d] - %lx\n, source, bytes, dest_maddr);
-memcpy((void *)dest_maddr, (void *)source, bytes);
+memcpy(maddr_to_virt(dest_maddr), (void *)source, bytes);
from_pos += bytes;
to_pos += bytes;
}
@@ -264,7 +275,8 @@ int xencomm_add_offset(void **handle, un
return xencomm_inline_add_offset(handle, bytes);
/* first we need to access the descriptor */
-desc = (struct xencomm_desc *)paddr_to_maddr((unsigned long)*handle);
+desc = (struct xencomm_desc *)
+xencomm_maddr_to_vaddr(paddr_to_maddr((unsigned long)*handle));
if (desc == NULL)
return -1;
@@ -310,7 +322,8 @@ int xencomm_handle_is_null(void *handle)
if (xencomm_is_inline(handle))
return xencomm_inline_addr(handle) == 0;
-desc = (struct xencomm_desc *)paddr_to_maddr((unsigned long)handle);
+desc = (struct xencomm_desc *)
+xencomm_maddr_to_vaddr(paddr_to_maddr((unsigned long)handle));
if (desc == NULL)
return 1;
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
--
Hollis Blanchard
IBM Linux Technology Center
Re: [XenPPC] [PATCH 1/4] xencomm take 2: xen side varisous fixes and preparation for consolidation
On Mon, 2007-08-13 at 12:59 +0900, Isaku Yamahata wrote:
- Xencomm should get_page()/put_page() after address conversion from paddr
to maddr because xen supports SMP and balloon driver.
Otherwise another vcpu may free the page at the same time.
Such a domain behaviour doesn't make sense, however nothing prevents it.
Unfortunately my test system is currently down, so I can't test this
today.
However, one initial comment: I really dislike the way get/put_page()
are scattered through this code. Maybe every pair is balanced today, but
it will be difficult to maintain, and especially to test all the error
paths.
I think this needs a more symmetrical API. Right now get_page() and
put_page() are being done at multiple levels, and in
xencomm_get_address() we're calling put_page() only to call get_page() a
moment later in xencomm_paddr_to_vaddr(). I don't have a concrete
proposal for simplifying this.
Also, it looks like we're calling put_page() on the 'desc' page itself
before we're done with it, so that's a bug.
+static int
+xencomm_paddr_to_vaddr(unsigned long paddr, unsigned long *vaddr,
+struct page_info **page)
Since we can use page_to_vaddr(), I don't think you need to pass 'vaddr'
here. That should simplify the code a little bit.
By the way, this looks bogus:
+static int
+xencomm_get_address(const void *handle, struct xencomm_desc *desc,
int i,
+unsigned long **address, struct page_info **page)
+{
+if (i == 0)
+*address = desc-address[0];
+else
+(*address)++;
Shouldn't that be *address = desc-address[i] ?
I definitely agree that some of these fixes are needed (especially
checking for the descriptor page overlap, and using get/put_page()).
However, this code is difficult to follow already, and these patches are
confusing *me* (and I wrote it! :) so I'm very nervous about increasing
the complexity.
Since the only issue you've identified is populate_physmap, and that has
an easy workaround, I would prefer the easier solution.
--
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] DOM0 can not be set up
On Fri, 2007-08-10 at 09:56 +0800, Jun Hui Bu wrote: According to the instructions in Xen wiki, Xen could not set up DOM0 guest OS(SLES10 SP1) when try it on JS20. Would you please help take a look it? Thanks a lot! How old is your source? The boot log contains this line: OF: Xen/PPC version 3.0-unstable ([EMAIL PROTECTED]) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) Sun Sep 9 09:34:58 EDT 2007 ... which is clearly inaccurate. What exact command line are you using to build Xen? How are you attaching your dom0? I've never used yaboot to boot Xen, but please paste your xen yaboot config. I find this interesting in particular: boot_of_module: Dom0 was loaded and found using r3/r4:0xf0[size 0x35d000] mod0: 63 L 3 Ì boot_of_module: dom0 mod @ 0x00f0[0x125d000] That mod0 output looks suspicious if it's supposed to be an ELF file... -- 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: [PATCH] [xen, xencomm] various xencomm fixes (was Re: [XenPPC] Re: [Xen-ia64-devel] [PATCH 1/2] remove xencomm page size limit(xen side))
On Tue, 2007-08-07 at 17:44 +0900, Isaku Yamahata wrote:
+/* get_page() to prevent from another vcpu freeing the page */
+static int
+xencomm_paddr_to_maddr(unsigned long paddr, unsigned long *maddr,
+struct page_info **page)
+{
+*maddr = paddr_to_maddr(paddr);
+if (*maddr == 0)
+return -EFAULT;
+
+*page = virt_to_page(*maddr);
+if (get_page(*page, current-domain) == 0) {
+if (page_get_owner(*page) != current-domain)
+/* This page might be a page granted by another domain */
+panic_domain(NULL, copy_from_guest from foreign domain\n);
+
+/* Try again. */
+return -EAGAIN;
+}
+
+return 0;
+}
PPC doesn't implement panic_domain(), so this doesn't build for me.
I don't see how we'd ever hit this case though, nor why we'd panic the
domain. How could paddr_to_maddr() ever return an maddr that doesn't
belong to the current domain? If paddr is invalid, an error should be
returned from there and propagated up, which is better than killing the
whole domain IMHO...
+*page = virt_to_page(*maddr);
This line doesn't make sense. Is it an maddr or a vaddr? If it's an
maddr, we shouldn't be passing it as virt to virt_to_page().
--
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] Re: [Xen-ia64-devel] [PATCH 1/2] remove xencomm page size limit(xen side)
On Thu, 2007-08-02 at 11:44 +0900, Isaku Yamahata wrote: But we can issue sequential p2m hcalls with different offsets, so we do. So what exactly is the new problem? The limit is about 64GB for xen/ia64 because xen/ia64 deafult page size is 16KB. The issue I'm seeing is the populate physmap hypercall failure at domain creation. It's essentially same issue you described above. I want to remove the limitation with the patches. Can't you simply issue repeated populate_physmap hypercalls, incrementing extent_start? Or, since you in fact probably don't need access to all 100GB during domain creation, can't you just map the area you need? (As a side question, is it really so difficult for you guys to just use the common code? I tried very hard to make it easy for you to just implement a couple hooks; I can't imagine it would take more than a day to do it.) Sorry for that. It seems to be good time to resolve it. I'll work on xencomm consolidation. No need to apologize, I'm just surprised that with all your xencomm work it hasn't already been done. -- 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] Re: please pull ppc/xen-unstable.hg
On Mon, 2007-07-30 at 17:11 -0500, Hollis Blanchard wrote: Hi Keir, please from http://xenbits.xensource.com/ext/ppc/xen-unstable.hg There are a pair of build fixes and support for the new multiboot2 loader in grub2. ... except I forgot to commit the new multiboot files. Please pull again to get them. -- 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] Re: [Xen-ia64-devel] [PATCH 1/2] remove xencomm page size limit(xen side)
On Wed, 2007-08-01 at 15:36 +0900, Isaku Yamahata wrote: remove xencomm page size limit. Currently xencomm has page size limit so that a domain with many memory (e.g. 100GB+) can't be created. This patch allows that the address array of struct xencomm_desc to cross page boundary so that the size of struct xencomm_desc can exceed page size. Note that struct xencomm_desc itself can't page boundary. I'm confused about this. We noticed a much smaller limit doing save/restore. The p2m mapping maxed out at 512MB: * a xencomm_desc must fit into 1 page (112) * it contains approx 19 64-bit entries * each entry points to a page of memory containing 19 entries of the p2m array * total: 118 p2m entries * each p2m entry represents a guest page (112) * 130 total guest memory can be represented with a single xencomm_desc But we can issue sequential p2m hcalls with different offsets, so we do. So what exactly is the new problem? Secondly, your patch doesn't make much sense to me, because the Xen side is explicitly rejecting xencomm_descs that cross a page boundary. So even if Linux sends down a multipage descriptor, Xen will return EINVAL. Am I missing something? (As a side question, is it really so difficult for you guys to just use the common code? I tried very hard to make it easy for you to just implement a couple hooks; I can't imagine it would take more than a day to do 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
[XenPPC] please pull ppc/xen-unstable.hg
Hi Keir, please from http://xenbits.xensource.com/ext/ppc/xen-unstable.hg There are a pair of build fixes and support for the new multiboot2 loader in grub2. -- 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] libvirt bad paddr patch for our hcall.c
On Wed, 2007-07-11 at 14:12 +0200, Christian Ehrhardt wrote: I added a new inline function invalid_endianness for better readability. An invalid address now returns -EINVAL and triggers a WARN_ON(). If a more sophisticated check is wanted later on like a additional 0x0C or something we can add this there on a central point. If we will need it somewhere else in the future we can move it to a header. Perhaps these messages should be quieted a little: (XEN) pfn2mfn: Dom[0] pfn 0x3f875eb00 is not a valid page (XEN) paddr_to_maddr: Dom:0 bad paddr: 0x3f875eb0 It also looks like we need to have the callers of paddr_to_maddr() (within Xen) do some error-checking and return the error. However, it isn't the kernel's job to be checking these addresses, so this patch isn't the right solution. -- 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] [PATCH] Take a writer lock for mmap_sem.
On Sat, 2007-07-07 at 10:20 +0100, Keir Fraser wrote:
Changes inside powerpc files are fine. Obviously powerpc-specific changes
inside common files are usually fine. Changes to locking protocols in common
files (e.g., changed usage of mmap_sem in privcmd.c) is *not* fine. Please
post patches for that kind of thing.
My mistake, I meant to send this separately.
In 2.6.17, we did our own locking inside direct_remap_pfn_range(). In
the current Linux tree though, the locking is done in privcmd_ioctl().
However, since direct_remap_pfn_range() is modifying the mm_struct,
shouldn't that be a a write lock rather than a read lock?
[XEN][LINUX] Take a writer lock for mmap_sem.
direct_remap_pfn_range() will be modifying the mm.
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff -r e5f633c33025 drivers/xen/privcmd/privcmd.c
--- a/drivers/xen/privcmd/privcmd.c Fri Jul 06 17:35:53 2007 +0100
+++ b/drivers/xen/privcmd/privcmd.c Mon Jul 09 10:07:32 2007 -0500
@@ -111,7 +112,7 @@ static int privcmd_ioctl(struct inode *i
if (copy_from_user(msg, p, sizeof(msg)))
return -EFAULT;
- down_read(mm-mmap_sem);
+ down_write(mm-mmap_sem);
vma = find_vma(mm, msg.va);
rc = -EINVAL;
@@ -153,7 +154,7 @@ static int privcmd_ioctl(struct inode *i
rc = 0;
mmap_out:
- up_read(mm-mmap_sem);
+ up_write(mm-mmap_sem);
ret = rc;
}
break;
@@ -176,14 +177,14 @@ static int privcmd_ioctl(struct inode *i
if ((m.num = 0) || (nr_pages (LONG_MAX PAGE_SHIFT)))
return -EINVAL;
- down_read(mm-mmap_sem);
+ down_write(mm-mmap_sem);
vma = find_vma(mm, m.addr);
if (!vma ||
(m.addr != vma-vm_start) ||
((m.addr + (nr_pages PAGE_SHIFT)) != vma-vm_end) ||
!privcmd_enforce_singleshot_mapping(vma)) {
- up_read(mm-mmap_sem);
+ up_write(mm-mmap_sem);
return -EINVAL;
}
@@ -191,7 +192,7 @@ static int privcmd_ioctl(struct inode *i
addr = m.addr;
for (i = 0; i nr_pages; i++, addr += PAGE_SIZE, p++) {
if (get_user(mfn, p)) {
- up_read(mm-mmap_sem);
+ up_write(mm-mmap_sem);
return -EFAULT;
}
@@ -202,7 +203,7 @@ static int privcmd_ioctl(struct inode *i
put_user(0xF000 | mfn, p);
}
- up_read(mm-mmap_sem);
+ up_write(mm-mmap_sem);
ret = 0;
}
break;
--
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] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add #ifdef ARCH_HAS_DEV_MEM to archtecture specific file_operations.
On Sat, 2007-07-07 at 10:01 +0100, Keir Fraser wrote: By the way, I wonder how PPC manages to build both drivers/char/mem.c and drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be that mem_fops defined by the Xen file is picked up by the generic file. If !ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up the Xen mem_fops? Hmmm, yeah. Looks like we haven't tested that... :) -- 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] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctlconversion for 64-bit kernels
On Fri, 2007-07-06 at 09:09 +0100, Jan Beulich wrote: --- a/fs/compat_ioctl.cThu Jul 05 17:25:47 2007 -0500 +++ b/fs/compat_ioctl.cThu Jul 05 17:26:48 2007 -0500 @@ -2948,6 +2953,18 @@ COMPATIBLE_IOCTL(LPRESET) /*LPGETSTATS not implemented, but no kernels seem to compile it in anyways*/ COMPATIBLE_IOCTL(LPGETFLAGS) HANDLE_IOCTL(LPSETTIMEOUT, lp_timeout_trans) + +#ifdef CONFIG_XEN +HANDLE_IOCTL(IOCTL_PRIVCMD_MMAP_32, privcmd_ioctl_32) +HANDLE_IOCTL(IOCTL_PRIVCMD_MMAPBATCH_32, privcmd_ioctl_32) +COMPATIBLE_IOCTL(IOCTL_PRIVCMD_HYPERCALL) Where does the hypercall argument translation happen? It happens inside privcmd_hypercall(). See http://xenbits.xensource.com/ext/linux-ppc-2.6.hg?file/04f6ad5d9232/arch/powerpc/platforms/xen/hcall.c (In that tree, the function is named arch_privcmd_hypercall.) IA64 and PPC both implement this function now; only x86 is left with #ifdefs in drivers/xen/privcmd/privcmd.c . COMPATIBLE_IOCTL is just about the ioctl itself, not the sub-structures. -- 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] [PATCH] [XEN][LINUX] Refactor grant table allocation into arch-specific code
3 files changed, 24 insertions(+), 14 deletions(-)
arch/ia64/xen/hypervisor.c |5 +
drivers/xen/core/gnttab.c | 31 +--
include/xen/gnttab.h |2 ++
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Date 1183738982 18000
# Node ID fced1ca6a18a7031c6857b45f7027455ec2bef7d
# Parent 790e4d5567dcd8bfb42ae1e67ad1f3dffd29ece1
[XEN][LINUX] Refactor grant table allocation into arch-specific code.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff -r 790e4d5567dc -r fced1ca6a18a arch/ia64/xen/hypervisor.c
--- a/arch/ia64/xen/hypervisor.cThu Jul 05 16:58:26 2007 -0500
+++ b/arch/ia64/xen/hypervisor.cFri Jul 06 11:23:02 2007 -0500
@@ -408,6 +408,11 @@ __xen_destroy_contiguous_region(unsigned
#include linux/mm.h
#include xen/interface/xen.h
#include xen/gnttab.h
+
+void *arch_gnttab_alloc_shared(unsigned long *frames)
+{
+ return __va(frames[0] PAGE_SHIFT);
+}
static void
gnttab_map_grant_ref_pre(struct gnttab_map_grant_ref *uop)
diff -r 790e4d5567dc -r fced1ca6a18a drivers/xen/core/gnttab.c
--- a/drivers/xen/core/gnttab.c Thu Jul 05 16:58:26 2007 -0500
+++ b/drivers/xen/core/gnttab.c Fri Jul 06 11:23:02 2007 -0500
@@ -430,7 +430,7 @@ static inline unsigned int max_nr_grant_
#ifdef CONFIG_XEN
-#ifndef __ia64__
+#ifdef CONFIG_X86
static int map_pte_fn(pte_t *pte, struct page *pmd_page,
unsigned long addr, void *data)
{
@@ -448,7 +448,15 @@ static int unmap_pte_fn(pte_t *pte, stru
set_pte_at(init_mm, addr, pte, __pte(0));
return 0;
}
-#endif
+
+void *arch_gnttab_alloc_shared(unsigned long *frames)
+{
+ struct vm_struct *area;
+ area = alloc_vm_area(PAGE_SIZE * max_nr_grant_frames());
+ BUG_ON(area == NULL);
+ return area-addr;
+}
+#endif /* CONFIG_X86 */
static int gnttab_map(unsigned int start_idx, unsigned int end_idx)
{
@@ -473,21 +481,16 @@ static int gnttab_map(unsigned int start
BUG_ON(rc || setup.status);
-#ifndef __ia64__
- if (shared == NULL) {
- struct vm_struct *area;
- area = alloc_vm_area(PAGE_SIZE * max_nr_grant_frames());
- BUG_ON(area == NULL);
- shared = area-addr;
- }
+ if (shared == NULL)
+ shared = arch_gnttab_alloc_shared(frames);
+
+#ifdef CONFIG_X86
rc = apply_to_page_range(init_mm, (unsigned long)shared,
PAGE_SIZE * nr_gframes,
map_pte_fn, frames);
BUG_ON(rc);
-frames -= nr_gframes; /* adjust after map_pte_fn() */
-#else
- shared = __va(frames[0] PAGE_SHIFT);
-#endif
+ frames -= nr_gframes; /* adjust after map_pte_fn() */
+#endif /* CONFIG_X86 */
kfree(frames);
@@ -623,7 +626,7 @@ int gnttab_resume(void)
int gnttab_suspend(void)
{
-#ifndef __ia64__
+#ifdef CONFIG_X86
apply_to_page_range(init_mm, (unsigned long)shared,
PAGE_SIZE * nr_grant_frames,
unmap_pte_fn, NULL);
diff -r 790e4d5567dc -r fced1ca6a18a include/xen/gnttab.h
--- a/include/xen/gnttab.h Thu Jul 05 16:58:26 2007 -0500
+++ b/include/xen/gnttab.h Fri Jul 06 11:23:02 2007 -0500
@@ -117,6 +117,8 @@ int gnttab_suspend(void);
int gnttab_suspend(void);
int gnttab_resume(void);
+void *arch_gnttab_alloc_shared(unsigned long *frames);
+
static inline void
gnttab_set_map_op(struct gnttab_map_grant_ref *map, maddr_t addr,
uint32_t flags, grant_ref_t ref, domid_t domid)
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctlconversion for 64-b
On Fri, 2007-07-06 at 17:09 +0100, Jan Beulich wrote: Hollis Blanchard [EMAIL PROTECTED] 06.07.07 17:44 Where does the hypercall argument translation happen? It happens inside privcmd_hypercall(). See http://xenbits.xensource.com/ext/linux-ppc-2.6.hg?file/04f6ad5d9232/arch/powerpc/platforms/xen/hcall.c (In that tree, the function is named arch_privcmd_hypercall.) IA64 and PPC both implement this function now; only x86 is left with #ifdefs in drivers/xen/privcmd/privcmd.c . COMPATIBLE_IOCTL is just about the ioctl itself, not the sub-structures. Hmm, I can't really see any structures being translated there, all I see is guest handles getting dereferenced. So I'm still unclear where you do the 32-bit layout to 64-bit layout conversion, but obviously I must be missing something. Which structures do you think need further conversion? We've already fixed all the shared structures (e.g. sysctl) to use explicitly-sized types, so the PowerPC port has always had proper interfaces. For example, look at the definition of xen_ulong_t on the different architectures. The x86 interfaces were frozen too early, cementing this problem for you. -- 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] please pull PowerPC trees
Hi Keir, thanks for merging the Linux patches we've been discussing. Please pull PowerPC Xen Linux support from http://xenbits.xensource.com/ext/ppc/linux-2.6.18-xen.hg Then, please pull from http://xenbits.xensource.com/ext/ppc/xen-unstable.hg Among other things, it includes changes necessary to run the new Linux 2.6.18 kernel. Thanks! -- 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] One more fix for the forward port
On Thu, 2007-06-21 at 15:53 +0200, Christian Ehrhardt wrote:
diff -r 1bf85f927393 include/asm-powerpc/io.h
--- a/include/asm-powerpc/io.h Thu Jun 21 08:04:49 2007 +0200
+++ b/include/asm-powerpc/io.h Thu Jun 21 10:31:39 2007 +0200
@@ -248,11 +248,13 @@ static inline void * phys_to_virt(unsign
{
return (void *)__va(address);
}
+#define bus_to_virt phys_to_virt
/*
* Change struct page to physical address.
*/
#define page_to_phys(page) (page_to_pfn(page) PAGE_SHIFT)
+#define page_to_bus page_to_phys
/* We do NOT want virtual merging, it would put too much pressure on
* our iommu allocator. Instead, we want drivers to be smart enough
diff -r 1bf85f927393 include/asm-powerpc/xen/asm/hypercall.h
--- a/include/asm-powerpc/xen/asm/hypercall.h Thu Jun 21 08:04:49 2007 +0200
+++ b/include/asm-powerpc/xen/asm/hypercall.h Thu Jun 21 09:56:55 2007 +0200
@@ -72,6 +72,9 @@ static inline unsigned long HYPERVISOR_h
return -ENOSYS;
}
+/* to compile gnttab_copy_grant_page() in drivers/xen/core/gnttab.c */
+#define HYPERVISOR_mmu_update(req, count, success_count, domid) ({BUG();0;})
+
struct privcmd_hypercall;
extern int privcmd_hypercall(struct privcmd_hypercall *hypercall);
diff -r 1bf85f927393 include/asm-powerpc/xen/asm/hypervisor.h
--- a/include/asm-powerpc/xen/asm/hypervisor.h Thu Jun 21 08:04:49 2007 +0200
+++ b/include/asm-powerpc/xen/asm/hypervisor.h Thu Jun 21 08:26:48 2007 +0200
@@ -131,6 +131,7 @@ int direct_remap_pfn_range(struct vm_are
#definepfn_to_mfn(x) (x)
#definemfn_to_pfn(x) (x)
#define phys_to_machine(phys) ((maddr_t)(phys))
+#define phys_to_machine_mapping_valid(pfn) (1)
/* VIRT - MACHINE conversion */
#define virt_to_machine(v) (phys_to_machine(__pa(v)))
@@ -239,6 +240,7 @@ static inline void set_phys_to_machine(u
#define pfn_pte_ma(pfn, prot) __pte(((pfn) PAGE_SHIFT) |
pgprot_val(prot))
typedef unsigned long maddr_t;
+typedef unsigned long paddr_t;
#ifdef CONFIG_XEN_SCRUB_PAGES
Hi Christian, as far as I can see the vast majority of this patch is not
needed; the only part that's required is
phys_to_machine_mapping_valid().
Also, I can't find any changeset with the hash 1bf85f927393 . Maybe that
was a local MQ changeset?
--
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] One more fix for the forward port
On Thu, 2007-07-05 at 13:07 -0500, Hollis Blanchard wrote: Hi Christian, as far as I can see the vast majority of this patch is not needed; the only part that's required is phys_to_machine_mapping_valid(). I take it back. Not sure how I wasn't seeing this before... -- 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] Re: [Xen-devel] [PATCH 0 of 6] PowerPC Linux patches
On Thu, 2007-07-05 at 22:41 +0100, Keir Fraser wrote: On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote: These patches reorganize arch-generic Xen Linux code, so I'm sending them by mail for review. If they are acceptable, I will commit them (and the PowerPC code that depends on them) to the PowerPC Linux tree so you can pull from there. Please review. Done, and three replies sent. I'll check them in myself. I don't pull in changes to common code from foreign trees as it's too much of a pain to review the changesets. If there are common-code changes in a foreign tree, I don't pull. This has worked fine with ia64 for a long time. Yup, you once asked me to commit common Xen changes to the PPC tree to pull from, but I agree that can make review/revision difficult. I will resend this patchqueue with the changes you suggested. -- 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] Re: [Xen-devel] [PATCH 3 of 6] [XEN][LINUX] Add architecture-generic xencomm infrastructure
On Thu, 2007-07-05 at 22:29 +0100, Keir Fraser wrote: On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote: diff -r 001c42f8079e -r e2681868041e drivers/xen/Kconfig --- a/drivers/xen/Kconfig Thu Jul 05 16:01:18 2007 -0500 +++ b/drivers/xen/Kconfig Thu Jul 05 16:01:18 2007 -0500 @@ -278,4 +278,7 @@ config XEN_BALLOON bool default y +config XEN_XENCOMM + bool + Shouldn't this have a 'depends on', and 'default y'? This will be selected by architectures that need 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] One more fix for the forward port
On Tue, 2007-06-19 at 13:49 +0200, Christian Ehrhardt wrote: The DomU now boots without visible issues, but at least on my system networking in DomU does not yet work - the DomU tihnk its working, but I can't get a connection from/to Dom0. @Hollis - currently you are the only one except me who has an up-to-date forward port patch queue - could you please verify if this is only an issue of my local setup by applying all my latest patches and see what works in your environment. Networking seems to be OK here. I'm using a very stripped down disk image for domU (actually I'm using http://xm-test.xensource.com/ramdisks/initrd-1.1-powerpc.img), so I haven't tested it heavily, but I can manually assign an unused IP address and ping both into and out of the domU. My domain profile contains vif = [ '' ], and so xend automatically creates a vif and bridges it to the physical network. I'm attaching the full MQ patch series to this mail. To use it, clone http://xenbits.xensource.com/linux-2.6.18-xen.hg , extract the tarball inside that directory (it creates .hg/patches), and hg qpush -a. If you're not already an MQ user, see http://www.selenic.com/mercurial/wiki/index.cgi/MqExtension or just patch by hand. I haven't figured out how to effectively share this queue, but since I think it's pretty much done at this point, we'll be able to commit and send upstream soon (but I will be traveling until July, so not too soon). -- Hollis Blanchard IBM Linux Technology Center patches.tgz Description: application/compressed-tar ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
RE: [XenPPC] Re: [Xen-devel] new repo layout?
[Dramatically pruning CC list.] You can get it from xen-unstable.hg. It only runs on PowerPC 970, and unfortunately that does not include Apple G5s due to firmware lockout. Xen does not allow you to run x86 code on PowerPC because that is emulation. For that problem, you might try qemu or IBM's System p Application Virtual Environment. On Mon, 2007-06-18 at 15:26 -0400, Jimmy Markakis wrote: Where may one obtain the latest copy of XEN for PPC? Also, will XEN support x86 virtualization (emulation or something similar) on POWER architecture? Thanks, James Markakis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Bulpin Sent: Monday, June 18, 2007 3:20 PM To: Ian Campbell; Jimi Xenidis Cc: [EMAIL PROTECTED]; Hollis Blanchard; James Bulpin; Aron Griffis; xen-ppc-devel; Alex Williamson; xen-ia64-devel Subject: RE: [XenPPC] Re: [Xen-devel] new repo layout? We're using our own patchbot script which pre-dates hg notification support. I'd be keen to change to the latter for these trees. Any objections? James -Original Message- From: Ian Campbell [mailto:[EMAIL PROTECTED] Sent: 18 June 2007 19:14 To: Jimi Xenidis Cc: Hollis Blanchard; [EMAIL PROTECTED]; James Bulpin; Aron Griffis; xen-ppc-devel; Alex Williamson; xen-ia64-devel Subject: Re: [XenPPC] Re: [Xen-devel] new repo layout? On Mon, 2007-06-18 at 13:40 -0400, Jimi Xenidis wrote: Any chance you can wire up the email notifications again? I'd gladly do so if I had even the foggiest clue how. I'd assumed there would be a hook in .hg/hgrc, ~/.hgrc or /etc/hgrc but I can't find anything of the sort anywhere on xenbits. James? What's the secret? Ian. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ Campbell Company, Inc.: The information in this e-mail may contain privileged/confidential information. If you are not the intended recipient, you must not read, use, copy or disseminate the information or take any action in reliance thereupon. If you have received this e-mail in error, please notify Campbell Company, Inc. immediately by e-mail or telephone and delete the e-mail and any attachments from any computer. The information in this e-mail does not constitute an offer to sell or the solicitation of an offer to buy any securities in any jurisdiction or for the benefit of any person. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- 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] dom0 auto-translate mmap()
Hi, as I'm porting the PPC patches to the current Linux tree, I noticed
this code in privcmd.c:
static int privcmd_mmap(struct file * file, struct vm_area_struct * vma)
{
/* Unsupported for auto-translate guests. */
if (xen_feature(XENFEAT_auto_translated_physmap))
return -ENOSYS;
... allow mmap to succeed ...
}
All addresses provided to Xen by an autotranslate guest are guest
physical addresses, which Xen then translates to machine: (domid, gpfn)
- (mfn). The problem is that dom0 actually needs to address memory
outside of its own domain allocation, but how can you distinguish a gpfn
from an mfn in this case?
PowerPC runs all domains, including dom0, in autotranslate mode, and
so we have a workaround for this problem. When we know we're trying to
map machine addresses (which is what the builder tools do), we simply
set the high bit in pfn before passing it down to Xen. Xen then knows
it's a machine address.
This limits autotranslate domains to 32 + 12 - 1 = 43 bits of address
space, which I think is reasonable, especially since most 64-bit
processors don't use many more bits than that anyways...
The net is that I would like to remove the above test. I wonder why it
was added in the first place? Somebody has a privileged autotranslate
domain and mistakenly tried to run the domain building tools?
--
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] Re: [Xen-devel] new repo layout?
On Mon, 2007-06-04 at 11:25 -0600, Alex Williamson wrote: Another option would be to move the ia64 and ppc trees into separate subdirectories of /ext/. I'm open to other alternatives. So far, this sounds like the best option. This way it would work just like the staging tree builds and would hopefully be less likely to get broken. We might also gain some flexibility in being able to create new repos in the subdirectory. Thanks, If you're suggesting moving all PPC repositories, including the Linux tree, into http://xenbits.xensource.com/ext/powerpc/ , then that's fine with me. Also, we want to replace xenppc-unstable.hg with a copy of xenppc-unstable-merge.hg, so it would make sense to do this at the same time. The issue is that xenppc-unstable.hg has a *lot* of non-upstream history, and Keir doesn't want to pull it all into xen-unstable.hg. xenppc-unstable-merge.hg is much cleaner. -- 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] Re: [Xen-devel] new repo layout?
On Mon, 2007-06-04 at 13:02 -0600, Alex Williamson wrote: On Mon, 2007-06-04 at 12:46 -0500, Hollis Blanchard wrote: On Mon, 2007-06-04 at 11:25 -0600, Alex Williamson wrote: Another option would be to move the ia64 and ppc trees into separate subdirectories of /ext/. I'm open to other alternatives. So far, this sounds like the best option. This way it would work just like the staging tree builds and would hopefully be less likely to get broken. We might also gain some flexibility in being able to create new repos in the subdirectory. Thanks, If you're suggesting moving all PPC repositories, including the Linux tree, into http://xenbits.xensource.com/ext/powerpc/ , then that's fine with me. Yep, I think this is the way to go. So we'll have: http://xenbits.xensource.com/ext/powerpc/ http://xenbits.xensource.com/ext/ia64/ Each will have a linux-2.6.18-xen.hg repo in it that will be maintained by the arch maintainers and used for pulls into upstream. The default arch Xen branch needs to be moved into the directory as well. I also think it might be good to standardize on names. I'd like the xen-ia64-unstable.hg repo to be renamed to xen-unstable.hg. This way we'll end up with common names like: /xen-unstable.hg /linux-2.6.18-xen.hg /staging/xen-unstable.hg /staging/linux-2.6.18-xen.hg /ext/ia64/xen-unstable.hg /ext/ia64/linux-2.6.18-xen.hg Sound good? Thanks, Sounds good to me. -- 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] [Fwd: xend fix]
This is a workaround that might get you past your current problem.
There were also another boatload of fixes to this code that just landed
30 minutes ago, so you should probably try tip again first.
--
Hollis Blanchard
IBM Linux Technology Center
---BeginMessage---
diff -r bb9ed6b69f8c tools/python/xen/xend/XendNode.py
--- a/tools/python/xen/xend/XendNode.py Thu May 03 07:42:35 2007 -0400
+++ b/tools/python/xen/xend/XendNode.py Thu May 03 07:00:07 2007 -0400
@@ -161,13 +161,13 @@ class XendNode:
# Initialise PIFs
# First configure ones off disk
-saved_pifs = self.state_store.load_state('pif')
-if saved_pifs:
-for pif_uuid, pif in saved_pifs.items():
-try:
-XendPIF.recreate(pif, pif_uuid)
-except CreateUnspecifiedAttributeError:
-log.warn(Error recreating PIF %s, pif_uuid)
+#saved_pifs = self.state_store.load_state('pif')
+#if saved_pifs:
+#for pif_uuid, pif in saved_pifs.items():
+#try:
+#XendPIF.recreate(pif, pif_uuid)
+#except CreateUnspecifiedAttributeError:
+#log.warn(Error recreating PIF %s, pif_uuid)
--
Mike D. Day
Virtualization Architect and Sr. Technical Staff Member, IBM LTC
Cell: 919 412-3900
ST: [EMAIL PROTECTED] | AIM: ncmikeday | Yahoo IM: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc
---End Message---
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] undef DEBUG in linuxppc time.c to prevent printk flooding
On Wed, 2007-05-02 at 10:47 +0200, Christian Ehrhardt wrote: diff -r 43dcc1cc2dd8 arch/powerpc/platforms/xen/time.c --- a/arch/powerpc/platforms/xen/time.c Thu Mar 01 14:42:25 2007 -0600 +++ b/arch/powerpc/platforms/xen/time.c Wed May 02 07:52:26 2007 +0200 @@ -6,7 +6,7 @@ #include asm/time.h #include asm/udbg.h -#define DEBUG +#undef DEBUG #ifdef DEBUG #define DBG(fmt...) printk(fmt) I committed something like this recently, so if you update your Linux tree it should be fixed. -- 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] please pull xenppc-unstable-merge
Hi Keir, please pull from http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg It contains two build fixes needed for 3.0.5 and one bug fix. Thanks! -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-changelog] [xen-unstable] xen: Split domain_flags into discrete first-class fields in the
On Fri, 2007-03-30 at 16:10 -0700, Xen patchbot-unstable wrote:
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1175177666 -3600
# Node ID 4b13fc910acf0019c27cbae35181433b381e88d1
# Parent 31f20aaac8188bc1366b80e55e47b328db425180
xen: Split domain_flags into discrete first-class fields in the
domain structure. This makes them quicker to access, and simplifies
domain pause and checking of runnable status.
diff -r 31f20aaac818 -r 4b13fc910acf xen/common/domain.c
--- a/xen/common/domain.c Thu Mar 29 13:29:24 2007 +0100
+++ b/xen/common/domain.c Thu Mar 29 15:14:26 2007 +0100
@@ -262,8 +264,12 @@ void domain_kill(struct domain *d)
{
domain_pause(d);
-if ( test_and_set_bit(_DOMF_dying, d-domain_flags) )
+/* Already dying? Then bail. */
+if ( xchg(d-is_dying, 1) )
return;
+
+/* Tear down state /after/ setting the dying flag. */
+smp_wmb();
gnttab_release_mappings(d);
domain_relinquish_resources(d);
You're now doing xchg() on a 1-byte variable, which does not work on
PowerPC.
This is an interface problem: using the interface in a way that works on
x86 fails on other architectures. PLEASE let's redefine the interface to
prevent this from happening. In this case, that means replacing the
xchg() macro with
static inline xchg(atomic_t *ptr, atomic_t val)
and changing the type of 'is_dying'.
--
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] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] xen: Split domain_flags into discrete first-class fields in the
On Thu, 2007-04-05 at 16:56 +0100, Keir Fraser wrote: On 5/4/07 16:44, Hollis Blanchard [EMAIL PROTECTED] wrote: This is an interface problem: using the interface in a way that works on x86 fails on other architectures. PLEASE let's redefine the interface to prevent this from happening. In this case, that means replacing the xchg() macro with static inline xchg(atomic_t *ptr, atomic_t val) and changing the type of 'is_dying'. Just need to define bool_t appropriately. What do you need: a long? An int would be fine, and that would solve today's problem. How will that prevent the same problem from recurring in the future? -- 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] Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] xen: Split domain_flags into discrete first-class fields in the
On Thu, 2007-04-05 at 17:59 +0100, Keir Fraser wrote: On 5/4/07 16:56, Keir Fraser [EMAIL PROTECTED] wrote: On 5/4/07 16:44, Hollis Blanchard [EMAIL PROTECTED] wrote: This is an interface problem: using the interface in a way that works on x86 fails on other architectures. PLEASE let's redefine the interface to prevent this from happening. In this case, that means replacing the xchg() macro with static inline xchg(atomic_t *ptr, atomic_t val) and changing the type of 'is_dying'. Just need to define bool_t appropriately. What do you need: a long? Does PowerPC support atomic byte loads and stores by the way (i.e., concurrent loads and stores to adjacent bytes by different processors do not conflict with each other)? Yes, there are single byte load and store instructions. In which case it might be worth keeping bool_t and defining atomic_bool_t or atomic_rmw_bool_t for bools that need to be atomically read-modified-written. That would avoid bloating critical structures for the few bools that need atomic r-m-w semantics. If that's your preference. However, as long as xchg() accepts all pointer types, this problem will reoccur. We've had the same problem with the set_bit() interface in the past, and I see x86 still uses a void* as the pointer argument there. x86 Linux doesn't use void* for bitops and it's for exactly this reason. These are not difficult changes to make, and solve real long-term maintenance problems. I'm sure if x86 had this issue, an arch-neutral API would have been in place from day one. -- 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] Launching DomU crashes Xen in xen-unstable
On Tue, 2007-03-27 at 18:03 -0500, Jerone Young wrote: (XEN) allocated RMA for Dom[1]: 0x42c00[0x400] (XEN) PFN is 0x2c000 (XEN) BUG at mm.c:134 This is an embarrassing bug. The machine address we're trying to map is 0x42c00. That is above 16GB, because the machine has 16GB of RAM plus a 2GB IO hole, meaning addresses up to 18GB are actually possible. However, the flag we use to indicate a foreign mapping is the 16GB bit, 0x4. (We unfortunately did not start with bits at the top of the address space.) Aside from having Xen pick another bit, we will need a Linux patch because that bit is hardcoded in some assembly. -- 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] Check for NULL source pointer
On Tue, 2007-03-27 at 19:18 -0400, Amos Waterland wrote:
While debugging the zImage problem on a JS21, I noticed that DOM0
bootargs was filled with bogus characters. I believe something like
this is necessary.
Signed-off-by: Amos Waterland [EMAIL PROTECTED]
---
ofd_fixup.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff -r cc72b77132f9 xen/arch/powerpc/ofd_fixup.c
--- a/xen/arch/powerpc/ofd_fixup.cWed Mar 21 18:29:49 2007 -0500
+++ b/xen/arch/powerpc/ofd_fixup.cTue Mar 27 19:13:03 2007 -0400
@@ -276,7 +276,10 @@ static ofdn_t ofd_chosen_props(void *m,
path[1], sizeof (path) - 1);
}
-strlcpy(bootargs, cmdline, sizeof(bootargs));
+memset(bootargs, 0, sizeof(bootargs));
+if (cmdline) {
+strlcpy(bootargs, cmdline, sizeof(bootargs));
+}
bsz = strlen(bootargs) + 1;
rm = sizeof (bootargs) - bsz;
Scary, it looks like we're doing strlen(NULL) in strlcpy(), which must
be returning a non-0 length (since the memory at 0 actually contains
instructions).
Nice catch, thanks.
--
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] please pull xenppc-unstable-merge.hg
Hi Keir, please pull from http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg I finally have beaten the domain builder into shape, which required a moving some x86 and ia64 code around. I've also fixed a few other build and runtime bugs that came down from recent xen-unstable changes. Separate topic: At this point, all PowerPC code is merged up. Because I was importing changesets from xenppc-unstable into xenppc-unstable-merge by hand, there's a bunch of old history left in xenppc-unstable. I would like to merge that in. The following commands executed in xen-unstable should do the right thing: hg tip hg pull http://xenbits.xensource.com/ext/xenppc-unstable.hg HGMERGE=/bin/true hg -y merge hg revert -a old tip hg commit It looks like that will bring in about 775 changesets without changing any code, but that's the amount of work you would have gotten all along; it's just coming in all at once (flooding xen-changelog). Also, not all of them have proper DCO lines. What do you think? (In general, I will say that manually importing selected changesets from a development tree into a merge tree was a bad idea, and I would be happy to elaborate for anybody who is considering this model.) -- 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] Profiling in xen – ppc considerations
On Mon, 2007-03-19 at 15:48 +0100, Christian Ehrhardt wrote:
Jimi Xenidis wrote:
...
There really very little Linux work to do here. We need:
1. An hcall that turn the performance monitor on for the domain
2. Save and restore the relevant registers for any domain that is has
it turned on.
3. Turn it off for domains that have it disabled.
you can see the hcall being setup here:
arch/powerpc/platforms/pseries/setup.c pSeries_setup_arch 322
ppc_md.enable_pmcs = pseries_lpar_enable_pmcs;
...
I have evaluated all three items you listed above and I think to know
now what to do to implement them in detail. I will post a refined
version of your list after I have clarified the last open thing. You
suggested to use the hcall to enable performance monitoring and I looked
at the definition. The hcall currently contains a lot of information
like perf granularity, function pointer, ...
There is no function pointer. There is high/low granularity. I
haven't really looked into this area so I'm not sure what those
correspond to, but at worst we could ignore them for now.
Currently I expect to need only to set a interdomain valid flag telling
xen there is some profiling in progress and optional a per domain flag
this one is currently profiling via an hcall for the first step of the
implementation. Because the guest can write all performance special
purpose registers xen needs only this flag to know if it has to
store/recover the perfmon registers.
We will need to restore MSR0/1,MSRA, PMC also for non-profiling guests
in context switch from a profiling one to non profiling guests, because
of that the easiest first implementation is something like the following
in context_switch().
...
if (perf_mon_in_use) {
save/restore MSR0/1,MSRA,PMC's
}
...
This will become more sophisticated in future but I currently expect
that we will not need the function pointer or profiling granularity
there for guest sampling. The only thing I currently expect for the
function pointer is to tell xen the place where to report hypervisor
samples in one of the next implementation steps.
Should/Can I use this complex hcall to set that simple flag e.g. by
skipping all other attributes or do we need a new one?
I think you should use the current H_PERFMON hcall. It's really not
complex...
--
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] Re: New domain builder in xen-unstable
On Wed, 2007-03-07 at 08:27 +, Keir Fraser wrote: The new domain builder infrastructure is not flexible enough for PowerPC, so we're sticking with our own xc_linux_build(). It sounded before like that would be possible, so I assume a20ec270998b was just an oversight? Hmm yes. You can #ifdef in the Python wrapper for now. But I'm surprised that you can't move to the new domain builder at all -- it has hooks for arch-dependent code to be inserted already, and we could add more if there's a need. It's pretty complex, which you may not realize since Gerd did the x86 work for you. FYI, I've been working on this for three days, and when I'm done I will only have un-broken PowerPC. Dubious use of time IMHO. I can't just ifdef PowerPC's xc_linux_build back in, because libelf doesn't map page-by-page like the old ELF loader did. That means I need to pre-map the memory, which starts dragging in xc_dom infrastructure. I'm tempted to copy-paste-and-hack that infrastructure, but I'm trying to be a good person and fit into the common code (avoiding ifdefs) wherever possible. Here's my current confusion: where are these ELF features described? Since PowerPC domU communicate only via GPFNs, do I need to set the auto-translated feature? What is the difference between dom-shadow_enable and xc_dom_feature_translated()? -- 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] Re: New domain builder in xen-unstable
On Fri, 2007-01-26 at 17:08 +, Keir Fraser wrote: xc_linux_build() is still provided in the 'new world' and is still used by xend. For ia64/x86 it is now a thin wrapper around Gerd's new domain-building infrastructure. For ppc you can continue to have your very own version under libxc/powerpc if you want to, and not use Gerd's new domain-building infrastructure. But the elf code that you rely on is going away, so you need to move to using libelf, which I'm sure Gerd can give you some pointers about. Hi Keir, it turns out I was confused about libxc, and we were depending on the just-removed ELF loader. I'm fixing that now; please give me a heads-up on the 3.0.5 release so I'm not caught out. Aside from that, it seems that xc_linux_build() is actually not called by anybody any longer. It looks like changeset a20ec270998b (from Brendan) removed the call from xc.c, replacing it with a call to the new style domain builder via xc_dom_linux_build(). The new domain builder infrastructure is not flexible enough for PowerPC, so we're sticking with our own xc_linux_build(). It sounded before like that would be possible, so I assume a20ec270998b was just an oversight? -- 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] last update broke asm - asm-powerpc link
On Mon, 2007-03-05 at 13:57 +0100, Christian Ehrhardt wrote: Hi, the current source that comes with a hg clone http://xenbits.xensource.com/ext/xenppc-unstable.hg; contains a broken include/asm subdir. This should be a link to asm-powerpc, or better it should not exist and will become created on demand as link e.g. asm-asm-powerpc. Since the last updates the repository contains a directory xen/include/asm which prevents the on demand creation of the link to the current architecture. I screwed up: I did 'hg add xen/include/asm/platform.h' instead of asm-powerpc. I think I've fixed it now. I also opened a Mercurial bug (http://www.selenic.com/mercurial/bts/issue509) to try to prevent this from happening in the future. -- 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] Re: [Xen-devel] please pull xenppc-unstable-merge.hg
On Fri, 2007-03-02 at 17:52 -0600, Hollis Blanchard wrote: Hi Keir, could you please pull from http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg ? There are two patches that touch common code: * Add a guest_physmap hook for max_mem changes. We've finally gotten around to removing a hack we've carried in the PowerPC tree for a while and we're using the guest_physmap_* hooks instead. At least for now we're using an array for p2m translation, and that means we need to know how big to make it. * Yamahata-san's PowerPC dynamic grant table patch. It looked a little hairy to me, but when I sat down with it I couldn't figure out how to improve it, at least until PowerPC gets rid of some assumptions about MFN locations. I had accidentally added a file in xen/include/asm (instead of asm-powerpc), which made asm a directory and broke the symlink creation. I've fixed that now. -- 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] FYI: xenppc-unstable updated
I pushed a xen-unstable merge to xenppc-unstable yesterday. It pretty much shouldn't matter, and we aren't all the way caught up with upstream xen-unstable yet, but just FYI. -- 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] Should the platform name be Xen-Maple
Jimi, the context is that we need to modify Fedora's installer so that it properly detects the system it's running on. That means we're implementing a user-visible interface right now. I think Xen-Maple is a terrible name to permanently commit ourselves to. Let's not. PPC's cpuinfo seems to have a split between platform and machine (where machine is more specific). I think platform = Xen is fine, and machine is the underlying machine. On Tue, 2007-02-27 at 14:56 -0500, Jimi Xenidis wrote: This comes from the fact that we are running xen from an underlying host platform. for example, if you boot linux without xen but on SLOF your machine name is Maple. see: arch/powerpc/platforms/xen/setup.c define_machine 246 define_machine(xen) I'd be interested in changing this to Xen for DomUs, but Dom0 should reflect the underlying machine type that linux would use without Xen. -JX On Feb 27, 2007, at 2:48 PM, Jerone Young wrote: In /proc/cpuinfo of a domain0 you see the following: processor : 0 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 1 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 2 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 3 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) timebase: 14318378 platform: Xen-Maple The platform line Xen-Maple is currently used by some tools in distros to identify the platform of the machine. The question I pose is should this be changed from Xen-Maple since running on Xen does not mean you are running on Maple. Something like Xen would probably be better. What do you guys think ? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel -- 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] Should the platform name be Xen-Maple
platform is build-time and comes from define_machine(). That should be Xen. machine we can display ourselves via ppc_md.show_cpuinfo(). We can get that from the device tree, just like CHRP does. On Tue, 2007-02-27 at 16:55 -0500, Jimi Xenidis wrote: I agree, but in our current Kernel source the string in question comes from the machine description. Am I missing something? -Jx On Feb 27, 2007, at 3:43 PM, Hollis Blanchard wrote: Jimi, the context is that we need to modify Fedora's installer so that it properly detects the system it's running on. That means we're implementing a user-visible interface right now. I think Xen- Maple is a terrible name to permanently commit ourselves to. Let's not. PPC's cpuinfo seems to have a split between platform and machine (where machine is more specific). I think platform = Xen is fine, and machine is the underlying machine. On Tue, 2007-02-27 at 14:56 -0500, Jimi Xenidis wrote: This comes from the fact that we are running xen from an underlying host platform. for example, if you boot linux without xen but on SLOF your machine name is Maple. see: arch/powerpc/platforms/xen/setup.c define_machine 246 define_machine(xen) I'd be interested in changing this to Xen for DomUs, but Dom0 should reflect the underlying machine type that linux would use without Xen. -JX On Feb 27, 2007, at 2:48 PM, Jerone Young wrote: In /proc/cpuinfo of a domain0 you see the following: processor : 0 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 1 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 2 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) processor : 3 cpu : PPC970MP, altivec supported clock : 2300.00MHz revision: 1.1 (pvr 0044 0101) timebase: 14318378 platform: Xen-Maple The platform line Xen-Maple is currently used by some tools in distros to identify the platform of the machine. The question I pose is should this be changed from Xen-Maple since running on Xen does not mean you are running on Maple. Something like Xen would probably be better. What do you guys think ? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel -- Hollis Blanchard IBM Linux Technology Center -- 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] Re: [Xen-devel] [PATCH] [GNTTAB] expandable grant table
On Mon, 2007-02-26 at 23:39 +, Keir Fraser wrote: On 26/2/07 23:31, Hollis Blanchard [EMAIL PROTECTED] wrote: Hi Yamahata-san, thanks very much for your patch! I'm confused about one thing though: why do we need to take a lock to read d-grant_table-nr_grant_frames? It's a simple integer, so no lock is required or useful. I haven't got the ppc code immediately to hand but the x86 code will dynamically grow the grant table based on requests made via the add_to_physmap hypercall, hence it needs to take the lock. OK, I see x86's XENMAPSPACE_grant_table handler; the locking makes sense there. I see ia64 takes it also even though it only reads from nr_grant_frames (it won;t dynamically expand via the add_to_physmap hypercall). That's possibly overkill although there is some concern over reading nr_grant_frames versus looking up a grant-table page that appears within the range [0, nr_grant_frames-1] which taking the lock trivially sidesteps. If ia64 didn't take the lock it might be possible to see an increased value of nr_grant_frames that the expand function hadn't yet fully installed the new grant-table pages for yet. I don't believe that's a concern, since updating grant_table-nr_grant_frames is the very last step in gnttab_grow_table(), and it will only grow. The comments about locking around nr_grant_frames() and nr_grant_entries() are confusing at best, since you don't need a lock to read an integer... -- 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] Re: xen heap size
On Fri, 2007-02-23 at 10:21 -0600, Ryan Harper wrote: The other method I was going to look into was to allocate dom0's rma, and then calculation would look like: dom0_start_mfn = page_to_mfn(d-arch.rma_base); dom0_overlap = (dom0_start_mfn + dom0_nrpages - rma_sz) - IO_SIZE_PAGES; Any other good way to figure how much of dom0's allocation will fall within 2-4G IO hole? Why are you looking for another approach? What's wrong with this solution? -- 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] Re: xen heap size
On Thu, 2007-02-22 at 16:07 -0600, Ryan Harper wrote: IIRC, when dom0 boots with 192MB (the default) I usually see ~19MB of heap available in the boot messages on js20. Looking at js21, I see: (XEN) Xen Heap: 135MiB (138548KiB) RMA different size on js21? That's an unusual size: it's slightly more than the second 64MB RMA boundary, which seems to indicate there's a lot of wasted memory before dom0 at 192MB. I wonder if this is related to the 4GB of memory in this system. A more complete boot log might shed some light on it. To answer your question, the 970MP (in JS21) supports the same RMA sizes as 970 and 970FX (in JS20). -- 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] Re: [Xen-devel] please pull xenppc-unstable-merge.hg
On Fri, 2007-02-09 at 14:58 -0600, Hollis Blanchard wrote: Hi Keir, please pull from http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg Among the PPC updates are the two libelf patches I sent separately. Hi Keir, any comments on this? -- 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] domain physical to machine address translation
I was talking with Ryan yesterday, and we settled on a scheme to resolve some of our current memory management ugliness. If we have a notification hook in the XEN_DOMCTL_max_mem handler, we could size an array for each domain containing a pointer into the frame_table per page. There are already hooks in increase/decrease_reservation, except we aren't using them! In particular: * When a domain's max_page is set, we allocate an appropriately sized array of pointers, initialized to NULL. * increase_reservation() calls guest_physmap_add_page() with domain, pfn, and mfn. domain-p2m[pfn] = mfn_to_page(mfn) * decrease_reservation() calls guest_physmap_remove_page() with the same parameters. domain-p2m[pfn] = NULL Benefits: * slightly simplify pfn2mfn(); in particular we could remove the RMA check, the extent list walk, and the grant table check. I think the IO and foreign checks wouldn't be as trivial, but maybe we could figure that out later * drastically improves performance for accessing high addresses in large domains (avoids the extent list walk) * enables memory ballooning, although some Linux work needed to avoid the RMA. By my calculations (which always need to be double-checked ;) the memory consumption of a pointer per page would be 1/500th, e.g. a 1GB domain would require a 2MB array. This memory would probably need to be allocated from the domain heap to avoid exhausting the Xen heap. We don't need to use an array long-term, though I think it's the easiest initial implementation. The simplest version of this patch would just replace the RMA and extent list walking in pfn2mfn(), so it's nothing radical. -- 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] Re: [Xen-devel] please pull xenppc-unstable-merge.hg
On Wed, 2007-02-14 at 18:55 +, Keir Fraser wrote: On 14/2/07 16:44, Hollis Blanchard [EMAIL PROTECTED] wrote: On Fri, 2007-02-09 at 14:58 -0600, Hollis Blanchard wrote: Hi Keir, please pull from http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg Among the PPC updates are the two libelf patches I sent separately. Hi Keir, any comments on this? Assuming all looks okay I'll merge the ppc tree in tomorrow morning. Great, thanks! Can I delete the old elf code after doing this merge (i.e., are you using libelf now)? Yes, we are using libelf now. -- 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] please pull xenppc-unstable-merge.hg
Hi Keir, please pull from http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg Among the PPC updates are the two libelf patches I sent separately. -- 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] Re: [Xen-changelog] [xen-unstable] Add RCU support to Xen.
On Sat, 2007-01-27 at 13:00 -0800, Xen patchbot-unstable wrote: # HG changeset patch # User [EMAIL PROTECTED] # Date 1169836476 0 # Node ID 32fd32bbf78d094e96027e3cea05fcbd92fee7a5 # Parent 19a600376688577f0692eac022f05bc6df30ce93 Add RCU support to Xen. ... @@ -658,6 +659,8 @@ void __init __start_xen(multiboot_info_t trap_init(); +rcu_init(); + timer_init(); early_time_init(); This patch only added the rcu_init() call for x86. When the call is omitted (on ia64 and powerpc), do_softirq() crashes trying to call a null function pointer. In cases like this where you *know* you're going to break the non-x86 architectures, please email xen-ppc-devel and xen-ia64-devel to let us know what we'll need to do in the future, rather than force us to reverse-engineer the crash. Thanks! -- 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] boot failure with large dom0
If the problem were that dom0 was only partially transferred, we would
see dom0 start to boot and fail. The boot_of_alloc_init message happens
way before that point.
The early boot code only tracks the first 32M of memory, and I believe
that is the problem here: we're overflowing the bitmap we're using to
track memory. Page 2000 is address 200 (32MB). Try this patch:
diff -r 20e5f508accc xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Feb 06 13:42:19 2007 -0600
+++ b/xen/arch/powerpc/boot_of.cWed Feb 07 16:38:24 2007 -0600
@@ -394,6 +394,9 @@ static void boot_of_alloc_init(int m, ui
u64 start;
u64 size;
+if (((ulong)_end PAGE_SHIFT) = MEM_AVAILABLE_PAGES)
+of_panic(image is too big);
+
rc = of_getprop(m, available, a, sizeof (a));
if (rc 0) {
int l = rc / sizeof(a[0]);
--
Hollis Blanchard
IBM Linux Technology Center
On Wed, 2007-02-07 at 16:20 -0600, Jerone Young wrote:
So it looks like the problem has to do with tftp which apears to have a
64MB send limit. The file is over this and so everything does not make
it. Adding a check for dom0 image size does not good since the image
itself is not fully transfered. Which make since why you get the error:
boot_of_alloc_init: pg :0x2000 of our image is different
at bootup.
On Wed, 2007-02-07 at 11:59 -0600, Hollis Blanchard wrote:
I use a vmlinux as dom0, but it's a stripped vmlinux. A vmlinux with
full debug symbols is 55MB here, which probably explains this problem.
Could you see how easy it would be to catch this problem at runtime and
have a nice panic? Checking dom0_len in __start_xen() would probably do
the trick, maybe something like:
if (dom0_start + dom0_len (3220))
panic(dom0 is too big);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Xencomm virutal Adress translation question?
On Sun, 2007-01-28 at 10:40 -0500, Jimi Xenidis wrote:
Ok, xencomm is simply a data structure that describes (we'll call it
the descriptor or desc) the physical memory that another data
structure occupies (we'll call data).
Sometimes this data is self described, such that all the data
exists on a single page, or proven to be physically contiguous, so it
is tagged as inline and no separate descriptor is necessary and
therefore no allocation (or free) is required, so lets only consider
when allocation is required.
There are two methods to create this desc: (1) _map_early() and (2)
_map().
_map_early() is used when allocation occurs from the stack and the
size of data is known to be a small number (less than 4) pages, this
is helpfull for performance and in cases where the allocator is
unavailable (too early or in interrupt). The descriptor returned
from this call does not require a corresponding free().
BTW: the above paragraph makes me want to rename _map_early() to
_map_auto() or _map_stack() which in an obvious manner explains why
no free() is needed. Hollis?
I already suggested calling it _noalloc().
Now to answer your question:
In the case of _map(), if the data cannot be inlined then a single
kernel page is allocated to describe up to 511 (+-1) pages of data,
this page is known to easily be translated from kernel_virtual to
kernel_physycal using __va() and __pa() function, so there should be
no problem in using:
desc = __pa(alloc_page());
and:
free_page(__va(desc));
BTW: xencomm_pa(), should only be used when building the contents of
desc in order to describe data, _not_ in creating the value of
desc, that should always be __pa().
Yup, using __va() and __pa() should work because desc is always obtained
via kmalloc(). The free code would need to look like this:
xencomm_free(xc) {
if is_inline(xc)
return
free_page(__va(xc))
}
--
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] Re: New domain builder in xen-unstable
On Fri, 2007-01-26 at 10:58 -0600, Hollis Blanchard wrote: On Fri, 2007-01-26 at 13:43 +, Keir Fraser wrote: Hi, This is a heads up, mainly to the PowerPC and IA64 folks, that Gerd's new domain builder (including new Elf parser) is now checked into xen-unstable. This has disabled the old builder and elf-parsing code which will shortly be removed entirely. So far the new libelf has only been run-tested on x86, so... For IA64: most of the code is in place, but the new code needs some run-testing and possibly some small fixups to get it working. For PPC: looks like you have your own domain builder, which you may or may not decide to merge with the main code (it would be nice to!). Not sure what you mean by our own domain builder; we've been implementing xc_linux_build() for quite a while now (and thus integrated with xend). Sorry, I misunderstood. I was seeing all the libelf churn, and I missed the fact that xc_linux_build() is going away entirely (?). I'm still not sure what you mean by our own domain builder -- there is simply no way we're going to add more ifdefs to tools/libxc/xc_linux_build.c (or equivalent)... -- 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] Introducing BSC
What exact model do you have: 8842-21X, 8842-41X, or 8842-42X? I assume you have a lot of them? -- Hollis Blanchard IBM Linux Technology Center On Mon, 2007-01-22 at 22:31 +0100, Mario Macías wrote: Hi Hollis, We are using JS20 machines. Regards En/na Hollis Blanchard ha escrit: On Mon, 2007-01-22 at 11:03 +0100, Mario Macías wrote: Dear Xen-PPC team, first of all I want to congratulate you for the great work you are doing with the Xen Power PC porting. Let me introduce myself: my name is Mario Macías, from Barcelona Supercomputing Center ( http://www.bsc.es ). We are absolutely interested in the usage of Xen for our research systems and, in the future, for production environment. Unfortunately, for the moment we cannot contribute with coding, but we expect to contribute to the improvement of Xen with our testing into research applications. Hi Mario, nice to meet you. :) What sort of PowerPC systems do you plan to use Xen on? ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] [RFC] Xencomm patch to fix modules
On Thu, 2007-01-18 at 17:16 -0500, Jimi Xenidis wrote:
On Jan 18, 2007, at 4:26 PM, Hollis Blanchard wrote:
On Thu, 2007-01-18 at 16:18 -0500, Jimi Xenidis wrote:
Hey, wouldn't virt_addr_valid() do?
I can pass a perfectly valid virtual address that is within a
physically discontiguous area of memory, and this function would
return
0.
hmm, I thought the page allocate in linux was contiguous, and:
fastcall void free_pages(unsigned long addr, unsigned int order)
{
if (addr != 0) {
BUG_ON(!virt_addr_valid((void *)addr));
__free_pages(virt_to_page((void *)addr), order);
}
}
So you're thinking that virt_addr_valid() has something to do with being
physically contiguous? I couldn't find any code or comments to suggest
that.
--
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] Re: [Xen-changelog] [xen-unstable] [HVM] save restore: new hyper-call
This patch breaks PowerPC, which does not supply arch_(get|
set)hvm_ctxt(). In fact, I don't see where IA64 supplies these either.
Please revert and refactor into arch_do_domctl(), thanks.
--
Hollis Blanchard
IBM Linux Technology Center
On Thu, 2007-01-18 at 19:05 -0800, Xen patchbot-unstable wrote:
# HG changeset patch
# User Tim Deegan [EMAIL PROTECTED]
# Date 1169138884 0
# Node ID 44668189f354a3d928e4e5a37df416ffc2992772
# Parent 1e590ddb127789cfde6ed29eef0127b79bfff2a8
[HVM] save restore: new hyper-call
Signed-off-by: Zhai Edwin [EMAIL PROTECTED]
add a pair of hyper-call for hvm guest context
---
tools/libxc/xc_domain.c | 44 +++
tools/libxc/xenctrl.h | 24 +++
xen/arch/x86/hvm/hvm.c|8 +
xen/arch/x86/hvm/intercept.c | 231
++
xen/common/domctl.c | 73
xen/include/asm-x86/hvm/domain.h | 17 ++
xen/include/asm-x86/hvm/support.h | 125
xen/include/public/domctl.h | 16 ++
8 files changed, 538 insertions(+)
...
diff -r 1e590ddb1277 -r 44668189f354 xen/common/domctl.c
--- a/xen/common/domctl.c Thu Jan 18 16:48:03 2007 +
+++ b/xen/common/domctl.c Thu Jan 18 16:48:04 2007 +
@@ -215,6 +215,39 @@ ret_t do_domctl(XEN_GUEST_HANDLE(xen_dom
}
break;
+case XEN_DOMCTL_sethvmcontext:
+{
+struct hvm_domain_context *c;
+struct domain *d;
+struct vcpu *v;
+
+ret = -ESRCH;
+if ( (d = find_domain_by_id(op-domain)) == NULL )
+break;
+
+ret = -ENOMEM;
+if ( (c = xmalloc(struct hvm_domain_context)) == NULL )
+goto sethvmcontext_out;
+
+v = d-vcpu[0];
+
+ret = -EFAULT;
+
+#ifndef CONFIG_COMPAT
+if ( copy_from_guest(c, op-u.hvmcontext.ctxt, 1) != 0 )
+goto sethvmcontext_out;
+
+ret = arch_sethvm_ctxt(v, c);
+#endif
+
+xfree(c);
+
+sethvmcontext_out:
+put_domain(d);
+
+}
+break;
+
case XEN_DOMCTL_pausedomain:
{
struct domain *d = find_domain_by_id(op-domain);
@@ -552,6 +585,46 @@ ret_t do_domctl(XEN_GUEST_HANDLE(xen_dom
}
break;
+case XEN_DOMCTL_gethvmcontext:
+{
+struct hvm_domain_context *c;
+struct domain *d;
+struct vcpu *v;
+
+ret = -ESRCH;
+if ( (d = find_domain_by_id(op-domain)) == NULL )
+break;
+
+ret = -ENOMEM;
+if ( (c = xmalloc(struct hvm_domain_context)) == NULL )
+goto gethvmcontext_out;
+
+v = d-vcpu[0];
+
+ret = -ENODATA;
+if ( !test_bit(_VCPUF_initialised, v-vcpu_flags) )
+goto gethvmcontext_out;
+
+ret = 0;
+if (arch_gethvm_ctxt(v, c) == -1)
+ret = -EFAULT;
+
+#ifndef CONFIG_COMPAT
+if ( copy_to_guest(op-u.hvmcontext.ctxt, c, 1) )
+ret = -EFAULT;
+
+xfree(c);
+#endif
+
+if ( copy_to_guest(u_domctl, op, 1) )
+ret = -EFAULT;
+
+gethvmcontext_out:
+put_domain(d);
+
+}
+break;
+
case XEN_DOMCTL_getvcpuinfo:
{
struct domain *d;
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] [RFC] Xencomm patch to fix modules
On Thu, 2007-01-18 at 16:18 -0500, Jimi Xenidis wrote: On Jan 18, 2007, at 1:55 PM, Hollis Blanchard wrote: On Thu, 2007-01-18 at 12:17 -0500, Jimi Xenidis wrote: I agree with most of Hollis's comments, but have some of my own. First, I do not think that the implementation of is_phys_contiguous() answers the question in its name and IMNSHO is bogus. Perhaps something like: mm/sparse.c vaddr_in_vmalloc_area 232 static int vaddr_in_vmalloc_area(void *addr) And use if (!vaddr_in_vmalloc_area) The name was my suggestion. It should be commented, but think about it: we don't care if something is vmalloc or not. We care if it's physically contiguous or not, so I strongly believe that should be the name of the test. I'm not big on functions that do not implement what the name says it does. It does exactly what the name says it does: it returns 0 if the area is known to be physically discontiguous, and 1 otherwise. It's called malloc, not allocate_from_buddy or allocate_first_from_bitmap. That's because you can provide any implementation of the interface, and it can change at any time, and when it does change, you don't need to change the callers. However, the worst that can happen is a false-negative, (unless it is an ioremap() address which would be other problems). Hey, wouldn't virt_addr_valid() do? I can pass a perfectly valid virtual address that is within a physically discontiguous area of memory, and this function would return 0. -- 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
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] 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
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] [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
[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_pages(start_blk, end_blk
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 0 of 4] [PATCH] move devtree creation to libxc
On Thu, 2007-01-11 at 13:42 -0500, Ryan Harper wrote: whitespace_cleanup.patch - whitespace clean-up in xc_linux_build.c fix_up_flatdevtree.patch - fix copyright notice in flatdevtree.c - fix pointer math in ft_add_rsvmap() - rename bph string block field to match spec I've pushed patches 1 and 2 (more on that in another email). By the way, don't forget it's 2007 in your copyright notices now. :) -- 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] oops: xenppc-unstable broken
While pushing a couple of Ryan's patches, I accidentally pushed a broken merge into xenppc-unstable. (I really don't know why I was trying to merge using my pristine tree.) So that tree is going to have some issues until I can sort it out. Sorry. -- 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] IPI problems
I mentioned that I accidentally pushed an upstream merge to
xenppc-unstable while it's still broken. There are a couple broken
things. First, DomU console stops mid-string early in boot. Could be an
event channel problem with the ring buffer; haven't investigated.
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)).
(When I comment out mpic_init() in dom0, Xen IPIs continue to work but
real IRQs (e.g. the IDE controller) fail in dom0.)
Why is this problem occurring only after an upstream merge? I don't
know. It's possible that some common IRQ code has changed to no longer
call the same arch-specific code, but I'm just speculating.
diff -r d6481755ade6 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 Fri Jan 12 17:12:27 2007 -0600
@@ -438,7 +438,9 @@ static void __init __start_xen(multiboot
domain_unpause_by_systemcontroller(dom0);
#ifdef DEBUG_IPI
-ipi_torture_test();
+//ipi_torture_test();
+extern void do_ipi_test(char c);
+do_ipi_test(0);
#endif
startup_cpu_idle_loop();
}
diff -r d6481755ade6 xen/common/keyhandler.c
--- a/xen/common/keyhandler.c Thu Jan 11 13:39:27 2007 -0600
+++ b/xen/common/keyhandler.c Fri Jan 12 17:44:46 2007 -0600
@@ -260,6 +260,16 @@ static void do_debug_key(unsigned char k
bit. */
}
+static void got_ipi(void *info)
+{
+printk(CPU %u got IPI\n, smp_processor_id());
+}
+
+void do_ipi_test(unsigned char key)
+{
+smp_call_function(got_ipi, NULL, 0, 0);
+}
+
void initialize_keytable(void)
{
open_softirq(KEYPRESS_SOFTIRQ, keypress_softirq);
@@ -286,6 +296,8 @@ void initialize_keytable(void)
#endif
register_irq_keyhandler('%', do_debug_key, Trap to xendbg);
+
+register_keyhandler('I', do_ipi_test, IPI test);
}
/*
diff -r d6481755ade6 xen/drivers/char/console.c
--- a/xen/drivers/char/console.cThu Jan 11 13:39:27 2007 -0600
+++ b/xen/drivers/char/console.cFri Jan 12 17:09:01 2007 -0600
@@ -246,7 +246,7 @@ static void sercon_puts(const char *s)
/* CTRL-switch_char switches input direction between Xen and DOM0. */
#define SWITCH_CODE (opt_conswitch[0]-'a'+1)
-static int xen_rx = 1; /* FALSE = serial input passed to domain 0. */
+static int xen_rx = 0; /* FALSE = serial input passed to domain 0. */
static void switch_serial_input(void)
{
diff -r d6481755ade6 xen/include/asm-powerpc/smp.h
--- a/xen/include/asm-powerpc/smp.h Thu Jan 11 13:39:27 2007 -0600
+++ b/xen/include/asm-powerpc/smp.h Fri Jan 12 17:03:59 2007 -0600
@@ -52,7 +52,7 @@ void smp_event_check_interrupt(void);
void smp_event_check_interrupt(void);
void send_IPI_mask(cpumask_t mask, int vector);
-#undef DEBUG_IPI
+#define DEBUG_IPI
#ifdef DEBUG_IPI
void ipi_torture_test(void);
#endif
--
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 xenminicom optimazation to work for modules
On Thu, 2007-01-11 at 12:12 -0600, Jerone Young wrote:
@@ -121,7 +156,7 @@ int HYPERVISOR_xen_version(int cmd, void
int HYPERVISOR_xen_version(int cmd, void *arg)
{
if (is_kernel_addr((unsigned long)arg)) {
- void *desc = xencomm_create_inline(arg);
+ void *desc = xencomm_create_inline(arg, sizeof(__u64));
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_xen_version),
cmd, desc);
}
return HYPERVISOR_xen_version_userspace(cmd, arg);
Any use of is_kernel_addr() is a red flag.
-void *xencomm_create_inline(void *ptr)
+void *xencomm_create_inline(void *ptr, unsigned long bytes)
{
unsigned long paddr;
+ unsigned long first_page;
+ unsigned long last_page;
- BUG_ON(!is_kernel_addr((unsigned long)ptr));
+ first_page = xencomm_vtop(ptr) PAGE_MASK;
+ last_page = xencomm_vtop(ptr + bytes) PAGE_MASK;
+
+ if (first_page != last_page)
+ return NULL;
I still think you should drop xencomm_vtop(). If ptr and ptr+bytes are
on different virtual pages, they will be on different physical pages
too, so we don't need to do the more expensive virtual-to-physical
translation you're doing here.
But anyways, let's think about abstracting this a little bit.
Pseudo-code below.
First, the test we really want is is this area of memory physically
contiguous? If so, we can do inline.
void *xencomm_map(void *ptr, ulong bytes)
{
if (is_phys_contiguous(ptr))
return xencomm_create_inline(ptr);
return xencomm_create(ptr, bytes);
}
In particular we know that vmalloc space, from which modules are
allocated, is not physically contiguous. Other code makes reference to
VMALLOC_START/END, so we can too:
int is_physically_contiguous(ulong addr)
{
return (ptr VMALLOC_START) || (ptr = VMALLOC_END);
}
We can have a separate early function:
#define xencomm_map_early(ptr, bytes) \
char xc_area[bytes*2]; \
__xencomm_map_early(ptr, bytes, xc_area)
void *__xencomm_map_early(void *ptr, ulong bytes, char *xc_area)
{
if (is_phys_contiguous(ptr))
return xencomm_create_inline(ptr);
return xencomm_create_mini(ptr, bytes, xc_area);
}
(We need that macro because the *caller* needs to allocate stack space.)
With these interfaces, all a caller needs to do is use xencomm_map() or
xencomm_map_early(), and all the details of inline or mini or regular
are hidden.
Does this make sense (to anybody)?
--
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] Remove invalid optimization
On Tue, 2007-01-09 at 15:19 -0600, Jerone Young wrote: 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 not contiguous. So this check is invalid. Have you tested this 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] [PATCH] [RFC] Fix xenminicom optimizations to work for module
On Wed, 2007-01-10 at 11:51 -0600, Jerone Young wrote:
diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Tue Dec 19 09:22:37 2006 -0500
+++ b/arch/powerpc/platforms/xen/gnttab.c Wed Jan 10 00:50:24 2007 -0600
@@ -264,7 +264,7 @@ int HYPERVISOR_grant_table_op(unsigned i
argsize = sizeof(setup);
frame_list = xencomm_create_inline(
- xen_guest_handle(setup.frame_list));
+ xen_guest_handle(setup.frame_list), 0);
set_xen_guest_handle(setup.frame_list, frame_list);
memcpy(op, setup, sizeof(setup));
@@ -286,7 +286,7 @@ int HYPERVISOR_grant_table_op(unsigned i
return -ENOSYS;
}
- desc = xencomm_create_inline(op);
+ desc = xencomm_create_inline(op, 0);
ret = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_grant_table_op), cmd,
desc, count);
Throughout your entire patch you're using a size of 0. That can't be
right.
diff -r bbf2db4ddf54 arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.cTue Dec 19 09:22:37 2006 -0500
+++ b/arch/powerpc/platforms/xen/hcall.cWed Jan 10 10:30:08 2007 -0600
@@ -63,7 +83,22 @@ EXPORT_SYMBOL(HYPERVISOR_console_io);
int HYPERVISOR_event_channel_op(int cmd, void *op)
{
- void *desc = xencomm_create_inline(op);
+ char xc_area[XENCOMM_MINI_AREA];
+ struct xencomm_desc *x_desc;
+ int rc;
+
+ void *desc = xencomm_create_inline(op, sizeof(evtchn_op_t));
+
+ if (desc == NULL) {
+ rc = xencomm_create_mini(xc_area, XENCOMM_MINI_AREA,
+ op, sizeof(evtchn_op_t), x_desc);
+ if (rc)
+ return rc;
+
+ rc =
plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
+ cmd, __pa(x_desc));
+ return rc;
+ }
return plpar_hcall_norets(XEN_MARK(__HYPERVISOR_event_channel_op),
cmd, desc);
You don't need both desc and x_desc. Just remove x_desc.
diff -r bbf2db4ddf54 drivers/xen/core/xencomm.c
--- a/drivers/xen/core/xencomm.cTue Dec 19 09:22:37 2006 -0500
+++ b/drivers/xen/core/xencomm.cWed Jan 10 01:15:50 2007 -0600
@@ -119,13 +119,59 @@ int xencomm_create(void *buffer, unsigne
return 0;
}
-void *xencomm_create_inline(void *ptr)
+void *xencomm_create_inline(void *ptr, unsigned long bytes)
{
unsigned long paddr;
-
- BUG_ON(!is_kernel_addr((unsigned long)ptr));
-
+ unsigned long first;
+ unsigned long last;
+
+ first = xencomm_vtop(ptr) PAGE_MASK;
+ last = xencomm_vtop(ptr+bytes) PAGE_MASK;
Rename first and last to something like first_phys_page and
last_phys_page.
Does this code actually work? It seemed like the problem with your other
patch was that xencomm_vtop() doesn't work early. A simpler but
overly-broad test could work here:
first_page = ptr PAGE_MASK;
last_page = (ptr + bytes) PAGE_MASK;
+ if (first != last)
+ return NULL;
paddr = (unsigned long)xencomm_pa(ptr);
BUG_ON(paddr XENCOMM_INLINE_FLAG);
return (void *)(paddr | XENCOMM_INLINE_FLAG);
}
How has this patch been tested?
--
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] Re: OF claim untrustworthy?
On Wed, 2007-01-10 at 13:55 -0500, Jimi Xenidis wrote: SLOF: - does implement, but does not update available, though recent resions might Current SLOF does. - claim will only tell you about conflicts its self - will not tell you about conflicts with other claims or loaded images Repeated identical claims cause an unknown exception at the Forth prompt, but don't succeed. I'm not sure if that becomes an error via the client interface. -- 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] 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]fix xencomm_copy_{from, to}_guest.
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.
Thanks Yamahata-san! I've asked Jerone (CCed) to give this a quick test.
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.
I couldn't agree more. I've posted comments on that before; please let
me know if anybody on the ia64 side has questions about 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] systemsim-gpul problems
On Fri, 2007-01-05 at 09:54 -0700, Yoder Stuart-B08248 wrote: 1449668513: (1449502549): IPv4 over IPv4 tunneling driver 1450457186: (1450290832): TCP bic registered 1450527304: (1450360932): NET: Registered protocol family 1 1450557364: (1450390979): NET: Registered protocol family 17 146000: [0]: (PC:0x0042FA80) : 7997.4 Kilo-In... 148000: [0]: (PC:0x0042FA80) : .3 Kilo-In... 15: [0]: (PC:0x004224B0) : .3 Kilo-In... This is interesting because it seems to indicate that we're spending lots of time in Xen (that's a Xen address). nm xen-syms | sort should help you figure out what function that is. -- 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
Hi Jimi, thanks for the comments.
I'm really not interested in reworking all this stuff, which is why I
took shortcuts like relocating the modules rather than spending effort
on your preferred solution. Unfortunately, all this code was intimately
linked with the multiboot structure, so I had to change it.
On Thu, 2007-01-04 at 12:27 -0500, Jimi Xenidis wrote:
On Jan 3, 2007, at 12:32 PM, Hollis Blanchard wrote:
Xen on x86 uses GRUB's multiboot capabilities to load an arbitrary
number of images, including Xen, dom0 kernel, dom0 initrd, and ACM
policy. On PowerPC, we've had to build Xen, the dom0 kernel and the
dom0
initrd all into the same file to get them loaded.
We also boot from yaboot which allows us to separate dom0 from xen,
as does newer PIBS firmware via r3 r4 and trivial to teach SLOF and
other OF how as well. Please do not assume that we are fully linked
only and do not remove that logic. Using your new boot loader case
should be additive.
I believe you yourself told me those other methods were unimportant and
could be removed. :)
With this patch, our memory map now looks
like this:
exception handlers (0x0 to 0x4000)
RTAS
Open Firmware device tree
RTAS and OFD are subject to avail properties in from OF and whether
or not they can be claimed. I don't think you should write code that
assumes they are here.
The code does not. Anyways, regardless of the exact placement (which is
subject to available), the order remains the same.
+static void *alloc_tag(int key, int len)
+{
+struct mb2_tag_header *tag;
+
Does len include sizeof(*tag)? it looks like it does, why not make it
implicit?
Since the the largest member of *tag is a uint32_t then it must be 4
byte aligned, please make sure your allocations are rounded up to 4
bytes, unless you _know_ that len is, but I'd do it anyway.
It's easy to go back and forth on this issue (I have already). In the
end this is best because you can alloc_tag(FOO, sizeof(foo));
+static char *boot_of_bootargs(char **dom0_cmdline)
+{
+static const char *sepr[] = { -- , || };
+char *p;
+int sepr_index;
int rc;
if (builtin_cmdline[0] == '\0') {
@@ -620,10 +644,22 @@ static void boot_of_bootargs(multiboot_i
of_panic(bootargs[] not big enough for /chosen/
bootargs\n);
}
-mbi-flags |= MBI_CMDLINE;
-mbi-cmdline = (ulong)builtin_cmdline;
-
of_printf(bootargs = %s\n, builtin_cmdline);
+
+/* look for delimiter: -- or || */
+for (sepr_index = 0; sepr_index ARRAY_SIZE(sepr); sepr_index+
+){
+p = strstr((char *)builtin_cmdline, sepr[sepr_index]);
Is the cast necessary?
Doesn't look like it.
+if (p != NULL) {
+/* Xen proper should never know about the dom0 args. */
+*(char *)p = '\0';
Why casting here?
This code was moved from another location where p was const. I'll fix.
+static int __init boot_of_rtas(void)
{
int rtas_node;
int rtas_instance;
@@ -1026,12 +1060,10 @@ static int __init boot_of_rtas(module_t
rtas_end = mem + size;
rtas_msr = of_msr;
-mod-mod_start = rtas_base;
-mod-mod_end = rtas_end;
return 1;
hmm, aren't you going to create a tag so you know where RTAS has been
placed and how big it is?
No. RTAS is not a module GRUB passes to kernels.
+/* Create a structure as if we were loaded by a multiboot
bootloader. */
+struct mb2_tag_header __init *boot_of_multiboot(void)
+{
+struct mb2_tag_start *start;
+struct mb2_tag_name *name;
+struct mb2_tag_module *xenmod;
+struct mb2_tag_end *end;
+char *xen_cmdline;
+char *dom0_cmdline = NULL;
+static char *namestr = xen;
+
+/* create start tag. start-size is filled in later. */
+start = alloc_tag(MB2_TAG_START, sizeof(*start));
+
+/* create name tag. */
+name = alloc_tag(MB2_TAG_NAME, sizeof(*name) + strlen(namestr));
Are you intentionally skipping the '\0' that in the alloc
Nope, good catch!
@@ -141,43 +143,9 @@ 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 (mod[i].mod_start (ulong)_start
-mod[i].mod_start (ulong)_end) {
-/* mod was linked in */
-continue;
-}
-
-if (s freemem)
-panic(module addresses must assend\n);
-
-free_xenheap(freemem, s);
-freemem = ALIGN_UP(mod[i].mod_end, PAGE_SIZE);
-
-}
-
-/* the rest of the xenheap, starting at the end
RE: [XenPPC] systemsim-gpul problems
On Thu, 2007-01-04 at 16:48 -0700, Yoder Stuart-B08248 wrote: Whad'ya know...if you wait long enough it works! So simulator performance is acceptable until mid-way through dom0 boot? It would be good to figure out the source of the slowdown. -- 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] systemsim-gpul problems: reserved memory areas
On Thu, 2007-01-04 at 14:15 -0700, Yoder Stuart-B08248 wrote: I have turned on debug prints in arch/powerpc/boot_of.c. One thing I'm puzzling over is why boot_of_alloc_init() is marking overlapping regions of memory. Does that make sense?? It doesn't exactly make sense, but in this case it's not a real problem... [snip] boot_of_alloc_init: marking 0x0 - 0x0^M boot_of_alloc_init: marking 0x0 - 0x400^M These two come from your Open Firmware device tree. They don't make sense IMHO. systemsim may have a bug in its device tree. We could also have a bug in the way we parse the available property, but I believe our code has been tested on PowerMac and SLOF, and it looks correct to me. boot_of_alloc_init: marking 0x40 - 0x88b000^M This is our code reserving Xen's text, _start to _end. boot_of_alloc_init: marking 0x0 - 0x3000^M This is our code reserving the exception handlers. -- 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] Re: patch flow
On Sun, 2006-12-17 at 18:00 +, Xen patchbot-xenppc-unstable wrote: # HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID b04e24db308f2215c6bafaf358d1c10da79f244f # Parent 965d3e42dddaf5971001f7d172d192f925537644 [XEN][POWERPC] get cpu_*_maps correct so physinfo and affinity is accurate Signed-off-by: Jimi Xenidis [EMAIL PROTECTED] Please commit all uncontroversial patches first to xenppc-merge, then pull xenppc-merge into xenppc-unstable. It's OK if we change our minds later and revert changesets in -merge. To recap, xenppc-merge contains patches going upstream; it is pulled directly into xen-unstable. xenppc-unstable is xen-unstable plus any temporary hacks we need to make progress. (When you define xenppc-unstable this way, it obviously should be a child tree, not a parent tree.) This will ensure that we never have the same difficulty staying in sync with xen-unstable that we've had in the past. -- 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] [patch] multiboot2 support
Xen on x86 uses GRUB's multiboot capabilities to load an arbitrary
number of images, including Xen, dom0 kernel, dom0 initrd, and ACM
policy. On PowerPC, we've had to build Xen, the dom0 kernel and the dom0
initrd all into the same file to get them loaded. Since we currently
boot directly from Open Firmware, early PPC Xen code then fakes up a
multiboot info structure which later PPC Xen code extracts data from.
GRUB2, which supports PowerPC, is defining a new multiboot format
because the original was far too x86-specific. That loader is not yet
committed but is fairly complete, so to test it out I'm adapting PPC Xen
to it.
This is the first step: I've replaced our early multiboot code to fake
up a multiboot2 structure instead. I haven't yet tried to boot this from
GRUB2, but we will likely want to continue supporting directly booting
from firmware so this code needs to work.
Of interest is that I've changed the memory map to simplify some of the
early memory allocation code (which unlike x86 tried to handle unordered
discontiguous allocations). With this patch, our memory map now looks
like this:
exception handlers (0x0 to 0x4000)
RTAS
Open Firmware device tree
boot allocator bitmap (common Xen code)
Xen heap
...
_start (0x40; 64MB)
[Xen text/data]
_end
modules
[dom0, dom0 initrd, etc]
Xen heap
...
[fixed size]
domain heap
...
[consumes all remaining memory]
Comments and testing are welcome, or I'll probably check this in in a
day or so.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff -r dbc74db14a4b 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.cWed Jan 03 10:50:07 2007 -0600
@@ -22,7 +22,7 @@
#include xen/config.h
#include xen/init.h
#include xen/lib.h
-#include xen/multiboot.h
+#include xen/multiboot2.h
#include xen/version.h
#include xen/spinlock.h
#include xen/serial.h
@@ -30,6 +30,7 @@
#include xen/sched.h
#include asm/page.h
#include asm/io.h
+#include asm/boot.h
#include exceptions.h
#include of-devtree.h
#include oftree.h
@@ -77,6 +78,28 @@ static int bof_chosen;
static int bof_chosen;
static struct of_service s;
+
+static unsigned char xentags[512];
+static int xentags_pos;
+
+static int of_printf(const char *fmt, ...)
+__attribute__ ((format (printf, 1, 2)));
+
+static void *alloc_tag(int key, int len)
+{
+struct mb2_tag_header *tag;
+
+if (xentags_pos + len sizeof(xentags))
+of_panic(Couldn't allocate multiboot tag.);
+
+tag = (struct mb2_tag_header *)(xentags + xentags_pos);
+tag-key = key;
+tag-len = len;
+
+xentags_pos += len;
+
+return tag;
+}
static int __init of_call(
const char *service, u32 nargs, u32 nrets, s32 rets[], ...)
@@ -160,8 +183,6 @@ static int __init of_write(int ih, const
return sum;
}
-static int of_printf(const char *fmt, ...)
-__attribute__ ((format (printf, 1, 2)));
static int __init of_printf(const char *fmt, ...)
{
static char buf[1024];
@@ -609,8 +630,11 @@ static ulong boot_of_mem_init(void)
return 0;
}
-static void boot_of_bootargs(multiboot_info_t *mbi)
-{
+static char *boot_of_bootargs(char **dom0_cmdline)
+{
+static const char *sepr[] = { -- , || };
+char *p;
+int sepr_index;
int rc;
if (builtin_cmdline[0] == '\0') {
@@ -620,10 +644,22 @@ static void boot_of_bootargs(multiboot_i
of_panic(bootargs[] not big enough for /chosen/bootargs\n);
}
-mbi-flags |= MBI_CMDLINE;
-mbi-cmdline = (ulong)builtin_cmdline;
-
of_printf(bootargs = %s\n, builtin_cmdline);
+
+/* look for delimiter: -- or || */
+for (sepr_index = 0; sepr_index ARRAY_SIZE(sepr); sepr_index++){
+p = strstr((char *)builtin_cmdline, sepr[sepr_index]);
+if (p != NULL) {
+/* Xen proper should never know about the dom0 args. */
+*(char *)p = '\0';
+p += strlen(sepr[sepr_index]);
+*dom0_cmdline = p;
+of_printf(%s: dom0 cmdline: %s\n, __func__, *dom0_cmdline);
+break;
+}
+}
+
+return builtin_cmdline;
}
static int save_props(void *m, ofdn_t n, int pkg)
@@ -894,8 +930,8 @@ static void __init boot_of_fix_maple(voi
}
}
}
-
-static int __init boot_of_serial(void *oft)
+
+void __init boot_of_serial(void *oft)
{
int n;
int p;
@@ -975,11 +1011,9 @@ static int __init boot_of_serial(void *o
__func__, ns16550.irq);
ns16550.irq = 0;
}
-
-return 1;
-}
-
-static int __init boot_of_rtas(module_t *mod, multiboot_info_t *mbi)
+}
+
+static int __init boot_of_rtas(void)
{
int rtas_node;
int rtas_instance;
@@ -1026,12 +1060,10 @@ static int __init boot_of_rtas(module_t
[XenPPC] Re: [Xen-devel] _text vs _start
On Wed, 2007-01-03 at 21:32 +, Keir Fraser wrote: On 3/1/07 9:22 pm, Hollis Blanchard [EMAIL PROTECTED] wrote: On Wed, 2007-01-03 at 15:07 -0600, Hollis Blanchard wrote: Given that you do arithmetic with _end, can you explain why you're not using _start, which is a standard symbol provided by the default linker script? My mistake; _start of course isn't a linker script symbol at all, but rather the entry point code. There is an unnecessary disagreement among architectures over what symbols should be used to mark section and image boundaries. We could reasonably agree on at least _start/_end and _stext/_etext I think. This would allow functions like is_kernel_text() to become generic, and make it obvious which labels kexec should be using. Sounds great to me. PowerPC already arranges for _start to be at the very beginning of .text, which is at the beginning of the first PT_LOAD segment... so the end result is that the address of _start is the same as our link address. We also provide _etext, and _end, but not _stext (currently). -- 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] schedule() vs softirqs
PowerPC's timer interrupt (called the decrementer) is a one-shot timer, not periodic. When it goes off, entering the hypervisor, we first set it very high so it won't interrupt hypervisor code, then raise_softirq(TIMER_SOFTIRQ). We know that timer_softirq_action() will then call reprogam_timer(), which will reprogram the decrementer to the appropriate value. We recently uncovered a bug on PowerPC where if a timer tick arrives just inside schedule() while interrupts are still enabled, the decrementer is never reprogrammed to that appropriate value. This is because once inside schedule(), we never handle any subsequent softirqs: we call context_switch() and resume the guest. I believe the tick problem affects periodic timers (i.e. x86) as well, though less drastically. With a CPU-bound guest, it would result in dropped ticks: TIMER_SOFTIRQ is set and not handled, and when the timer expires again it is re-set. In other cases, it would result in some timer ticks being delivered very late. I don't know what effect this might have on guests, perhaps with sensitive time-slewing code. In addition, when SCHEDULE_SOFTIRQ is set, all greater softirqs (including NMI) will not be handled until the next hypervisor invocation. This is pretty anti-social behavior for a softirq handler. One solution would be to have schedule() *not* call context_switch() directly, but rather set a flag (or a next vcpu pointer) and return. That would allow other softirqs to be processed normally. Once do_softirq() returns to assembly, we can check the next vcpu pointer and call context_switch(). (This solution would enable a PowerPC optimization as well: we would like to lazily save non-volatile registers. We can't do this unless the exception handler regains control from do_softirq() before context_switch() is called.) Thoughts? -- 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] Re: [Xen-devel] schedule() vs softirqs
On Fri, 2006-12-15 at 17:36 +, Keir Fraser wrote: On 15/12/06 17:27, Hollis Blanchard [EMAIL PROTECTED] wrote: We recently uncovered a bug on PowerPC where if a timer tick arrives just inside schedule() while interrupts are still enabled, the decrementer is never reprogrammed to that appropriate value. This is because once inside schedule(), we never handle any subsequent softirqs: we call context_switch() and resume the guest. Easily fixed. You need to handle softirqs in the exit path to guest context. You need to do this final check with interrupts disabled to avoid races. Ah OK, I see now how x86 is doing that. I don't think that code flow really makes sense: why would you jump out of do_softirq() into assembly just to call do_softirq() again? Also, that doesn't solve the lazy register saving problem. However, I think I see how we can implement our desired context_switch() scheme in arch-specific code. The context_switch() call in schedule() will return, so please don't add a BUG() after that. :) -- 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] copy_page speedup using dcbz on target
On Fri, 2006-12-15 at 11:50 -0500, poff wrote: Using dcbz avoids first reading a cache line from memory before writing to the line. Timing results (starting with clean cache, ie no write-backs for dirty lines): So do you have a patch for copy_page()? -- 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] copy_page speedup using dcbz on target
On Fri, 2006-12-15 at 16:40 -0500, poff wrote:
So do you have a patch for copy_page()?
In Xen for PPC, the only copy_page() is in arch/powerpc/mm.c:
extern void copy_page(void *dp, void *sp)
{
if (on_systemsim()) {
systemsim_memcpy(dp, sp, PAGE_SIZE);
} else {
memcpy(dp, sp, PAGE_SIZE);
}
}
Correct.
1) Also copy_page is not referenced in current Xen sources?
In that case, why are you playing with it?
2) dcbz depends on cacheability and cache alignment.
Should a newname be given to this version of copy_page()?
page indicates cacheline-aligned.
Who calls copy_page() with non-cacheable memory?
3) Useful when PPC must do page copies in place of 'page flipping'.
So you're saying we should worry about it later?
--
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] copy_page speedup using dcbz on target
On Fri, 2006-12-15 at 17:50 -0500, poff wrote:
3) Useful when PPC must do page copies in place of 'page flipping'.
So you're saying we should worry about it later?
For the future, copy_page using dcbz:
diff -r 7669fca80bfc xen/arch/powerpc/mm.c
--- a/xen/arch/powerpc/mm.c Mon Dec 04 11:46:53 2006 -0500
+++ b/xen/arch/powerpc/mm.c Fri Dec 15 17:52:58 2006 -0500
@@ -280,7 +280,8 @@ extern void copy_page(void *dp, void *sp
if (on_systemsim()) {
systemsim_memcpy(dp, sp, PAGE_SIZE);
} else {
-memcpy(dp, sp, PAGE_SIZE);
+ clear_page(dp);
+ __copy_page(dp, sp);
}
}
diff -r 7669fca80bfc xen/include/asm-powerpc/page.h
--- a/xen/include/asm-powerpc/page.h Mon Dec 04 11:46:53 2006 -0500
+++ b/xen/include/asm-powerpc/page.h Fri Dec 15 17:52:58 2006 -0500
@@ -90,6 +90,25 @@ 1: dcbz0,%0\n\
extern void copy_page(void *dp, void *sp);
+static __inline__ void __copy_page(void *dp, void *sp)
+{
+ ulong dwords, dword_size;
+
+ dword_size = 8;
+ dwords = (PAGE_SIZE / dword_size) - 1;
+
+ __asm__ __volatile__(
+ mtctr %2 # copy_page\n\
+ ld %2,0(%1)\n\
+ std %2,0(%0)\n\
+1: ldu %2,8(%1)\n\
+ stdu%2,8(%0)\n\
+ bdnz1b
+ : /* no result */
+ : r (dp), r (sp), r (dwords)
+ : %ctr, memory);
+}
+
I'd rather have copy_page() dcbz; stdu; stdu; stdu; ... stdu; in each
loop iteration.
It would also be nice to improve memcpy, though that one is certainly
more difficult due to alignment, varying lengths, etc. Perhaps we can
borrow code from
http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
--
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] Re: [Xen-devel] schedule() vs softirqs
On Fri, 2006-12-15 at 21:39 +, Keir Fraser wrote: On 15/12/06 20:41, Hollis Blanchard [EMAIL PROTECTED] wrote: It's an issue with any architecture with a large number of registers which aren't automatically saved by hardware (and a C ABI that makes some of them non-volatile). x86 has a small number of registers. ia64 automatically saves them (from what I understand). So of the currently-supported architectures, yes, that leaves PowerPC. I see. It sounds like returning from context_switch() is perhaps the right thing for powerpc. That would be easier if you have per-cpu stacks (like ia64). Yup, we have per-cpu stacks. If not there are issues in saving register state later (and hence delaying your call to context_saved()) as there are calls to do_softirq() outside your asm code (well, not many, but there is one in domain.c for example) where you won't end up executing your do_softirq() wrapper. In general we'd like to reserve the right to include voluntary yield points, and that won't mix well with lazy register saves and per-physical-cpu stacks. Oh, we have per-physical-cpu stacks. We can do that because there's no such thing as a hypervisor thread which could block in hypervisor space and need to be restored later. Are you saying in the future you want to have hypervisor threads, and so we'll need per-VIRTUAL-cpu stacks? -- 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] Re: [Xen-devel] Please pull
On Sat, 2006-12-09 at 13:53 +, Keir Fraser wrote: Just check all these patches into the PPC tree and I’ll merge them into unstable with the rest. I always check the diff when I merge anyway. OK, they are now committed. Please hg pull http://xenbits.xensource.com/xenppc-unstable-merge.hg and let me know if you have any issues or questions. -- 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] Change to add boot param delimiter ||
On Wed, 2006-12-06 at 14:03 -0600, Jerone Young wrote: Thanks Hollis for the feedback. Added changes. Signed-off-by: Jerone Young [EMAIL PROTECTED] Applied; thanks. -- 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] [PATCH][XEN][POWERPC] allocate shadow memory for PPC Linux domains
Allocate shadow memory for PPC Linux domains. Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] diff -r 9d83185b4c37 tools/python/xen/xend/image.py --- a/tools/python/xen/xend/image.pyFri Dec 01 19:11:02 2006 -0500 +++ b/tools/python/xen/xend/image.pyTue Dec 05 10:44:22 2006 -0600 @@ -246,6 +246,15 @@ class PPC_LinuxImageHandler(LinuxImageHa features = self.vm.getFeatures(), arch_args = devtree.to_bin()) +def getRequiredShadowMemory(self, shadow_mem_kb, maxmem_kb): +@param shadow_mem_kb The configured shadow memory, in KiB. +@param maxmem_kb The configured maxmem, in KiB. +@return The corresponding required amount of shadow memory, also in +KiB. +PowerPC currently uses shadow memory to refer to the hash table. +return max(maxmem_kb / 64, shadow_mem_kb) + + class PPC_ProseImageHandler(LinuxImageHandler): ostype = prose -- 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] [PATCH][XEN][POWERPC] avoid xc_get_tot_pages() in the prose builder
Avoid xc_get_tot_pages() in the prose builder. Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] diff -r 9d83185b4c37 tools/libxc/powerpc64/xc_prose_build.c --- a/tools/libxc/powerpc64/xc_prose_build.cFri Dec 01 19:11:02 2006 -0500 +++ b/tools/libxc/powerpc64/xc_prose_build.cFri Dec 01 17:18:44 2006 -0600 @@ -230,6 +230,7 @@ static void free_page_array(xen_pfn_t *p int xc_prose_build(int xc_handle, uint32_t domid, + unsigned int mem_mb, const char *image_name, const char *initrd_name, const char *cmdline, @@ -257,8 +258,7 @@ int xc_prose_build(int xc_handle, DPRINTF(cmdline=%s\n, cmdline); -DPRINTF(xc_get_tot_pages\n); -nr_pages = xc_get_tot_pages(xc_handle, domid); +nr_pages = mem_mb (20 - PAGE_SHIFT); DPRINTF(nr_pages 0x%lx\n, nr_pages); rma_pages = get_rma_pages(devtree); diff -r 9d83185b4c37 tools/libxc/xenguest.h --- a/tools/libxc/xenguest.hFri Dec 01 19:11:02 2006 -0500 +++ b/tools/libxc/xenguest.hTue Dec 05 10:45:10 2006 -0600 @@ -124,6 +124,7 @@ int xc_get_hvm_param( int xc_prose_build(int xc_handle, uint32_t domid, + unsigned int mem_mb, const char *image_name, const char *ramdisk_name, const char *cmdline, diff -r 9d83185b4c37 tools/python/xen/xend/image.py --- a/tools/python/xen/xend/image.pyFri Dec 01 19:11:02 2006 -0500 +++ b/tools/python/xen/xend/image.pyTue Dec 05 10:44:22 2006 -0600 @@ -273,6 +282,7 @@ class PPC_ProseImageHandler(LinuxImageHa devtree = FlatDeviceTree.build(self) return xc.prose_build(dom= self.vm.getDomid(), + memsize= mem_mb, image = self.kernel, store_evtchn = store_evtchn, console_evtchn = console_evtchn, -- 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] [PATCH][XEN][POWERPC] add alloc_real_mode_area to python xc object
Export PowerPC-specific alloc_real_mode_area() via the 'xc' Python
object. As suggested, the function is prefixed with arch_ to easily
distinguish it from general xc functions.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff -r 9d83185b4c37 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h Fri Dec 01 19:11:02 2006 -0500
+++ b/tools/libxc/xenctrl.h Thu Dec 07 17:45:36 2006 -0600
@@ -439,6 +439,10 @@ int xc_domain_memory_populate_physmap(in
unsigned int address_bits,
xen_pfn_t *extent_start);
+int xc_alloc_real_mode_area(int xc_handle,
+uint32_t domid,
+unsigned int log);
+
int xc_domain_ioport_permission(int xc_handle,
uint32_t domid,
uint32_t first_port,
diff -r 9d83185b4c37 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c Fri Dec 01 19:11:02 2006 -0500
+++ b/tools/python/xen/lowlevel/xc/xc.c Thu Dec 07 17:45:38 2006 -0600
@@ -809,6 +809,28 @@ static PyObject *pyxc_domain_memory_incr
return zero;
}
+#ifdef __powerpc__
+static PyObject *pyxc_alloc_real_mode_area(XcObject *self,
+ PyObject *args,
+ PyObject *kwds)
+{
+uint32_t dom;
+unsigned int log;
+
+static char *kwd_list[] = { dom, log, NULL };
+
+if ( !PyArg_ParseTupleAndKeywords(args, kwds, ii, kwd_list,
+ dom, log) )
+return NULL;
+
+if ( xc_alloc_real_mode_area(self-xc_handle, dom, log) )
+return PyErr_SetFromErrno(xc_error);
+
+Py_INCREF(zero);
+return zero;
+}
+#endif
+
static PyObject *pyxc_domain_ioport_permission(XcObject *self,
PyObject *args,
PyObject *kwds)
@@ -1184,6 +1206,16 @@ static PyMethodDef pyxc_methods[] = {
dom [int]: Identifier of domain.\n
mem_kb [long]: .\n
Returns: [int] 0 on success; -1 on error.\n },
+
+#ifdef __powerpc__
+{ arch_alloc_real_mode_area,
+ (PyCFunction)pyxc_alloc_real_mode_area,
+ METH_VARARGS | METH_KEYWORDS, \n
+ Allocate a domain's real mode area.\n
+ dom [int]: Identifier of domain.\n
+ log [int]: Specifies the area's size.\n
+ Returns: [int] 0 on success; -1 on error.\n },
+#endif
{ domain_ioport_permission,
(PyCFunction)pyxc_domain_ioport_permission,
--
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] PowerPC patches
Hi Keir, I'd like to have you pull the PowerPC tree now. However, so that you can be sure we haven't affected operation on other architectures, I've split out the PPC patches that touch non-PPC files and am submitting them separately. Once these are applied, I'll merge and ask you to pull the PPC merge tree. -- 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] 'xm restore' following boot
On Thu, 2006-12-07 at 17:11 -0500, poff wrote: Also today there have been several runs similar to example 2. I modified python code to skip the 'unpause' at the end of domain restore. The drill: boot, xend start, xm restore, then another activity eg rebuild tools or search kernel tree, finally xm unpause. The guest domain often runs ok! If the 'other activity' is skipped and restored domain is unpaused immediately, almost always wedges. Could this be an issue with flushing the icache? -- 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] Change to add boot param delimiter ||
On Wed, 2006-12-06 at 11:37 -0600, Jerone Young wrote:
Update patch with Jimi's suggestions:
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 9148f7816d00 xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Oct 24 19:11:00 2006 -0400
+++ b/xen/arch/powerpc/boot_of.cWed Dec 06 11:34:37 2006 -0600
@@ -964,10 +964,11 @@ static void * __init boot_of_module(ulon
static module_t mods[4];
ulong mod0_start;
ulong mod0_size;
-static const char sepr[] = -- ;
+static const char * sepr[] = { -- , || };
+int sepr_index = 0;
extern char dom0_start[] __attribute__ ((weak));
extern char dom0_size[] __attribute__ ((weak));
-const char *p;
+const char *p = NULL;
int mod;
void *oft;
@@ -1020,11 +1021,17 @@ static void * __init boot_of_module(ulon
of_printf(%s: dom0 mod @ 0x%016x[0x%x]\n, __func__,
mods[mod].mod_start, mods[mod].mod_end);
-p = strstr((char *)(ulong)mbi-cmdline, sepr);
+
+/* look for deliminator -- or || is delimator */
delimiter
+for(sepr_index; sepr_index ARRAY_SIZE(sepr); sepr_index++){
Add a space after for, and move the sepr_index = 0 initialization
here please.
+p = strstr((char *)(ulong)mbi-cmdline, sepr[sepr_index]);
+if (p != NULL)
+break;
+}
+
if (p != NULL) {
/* Xen proper should never know about the dom0 args. */
-*(char *)p = '\0';
-p += sizeof (sepr) - 1;
+p += strlen(sepr[sepr_index]);
mods[mod].string = (u32)(ulong)p;
of_printf(%s: dom0 mod string: %s\n, __func__, p);
}
You've removed the code where we terminate Xen's arguments with a NULL
char.
Fix these issues and I'm quite happy with 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
