Re: [XenPPC] Has anyone gotten XEN running on either of these systems? IBM IntelliStation POWER 185 Express or Apple G5 Quad?
On Dec 3, 2007, at 2:36 PM, James Markakis wrote: Has anyone gotten XEN running on either of these systems? IBM IntelliStation POWER 185 Express http://www-03.ibm.com/systems/intellistation/power/hardware/185/ index.html Sorry, this already runs a hypervisor in the sock firmware, so you cannot access the hypervisor mode of the processor. Apple G5 Quad http://www.apple.com/pr/library/2005/oct/19pmg5.html See http://wiki.xensource.com/xenwiki/XenPPC/NoHV for info on this. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Which hg repository?
Sorry Christian,
A lot of us have been at a conference this week.
Anyway... All our bits are in the the proper Xen development
repositories
The build instructions are the same, but you get the bits from there.
-JX
On Sep 26, 2007, at 2:07 AM, Christian Kaiser2 wrote:
Hi,
I found out that http://xenbits.xensource.com/ext/ppc/xen-
unstable.hg
tree builds and works fine for me. What I described in my last post
was for
http://xenbits.xensource.com/xen-unstable.hg; tree.
But there is still another thing that does not work for me. I've
build the
hypervisor, the kernel and the tools. I can boot into the
hypervisor (using
yaboot), the hypervisor is able to load the kernel. Xend executes
with some
errors:
ioctl32(blktapctrl:3415): Unknown cmd fd(4) cmd(0003){00} arg
(0003)
on /dev/xen/blktap0
ioctl32(blktapctrl:3415): Unknown cmd fd(4) cmd(0004){00} arg
(0d57)
on /dev/xen/blktap0
The main problem is to create a domU. It fails with the error that
cannot
open /proc/xen/balloon. The balloon driver is disabled for ppc in
the xen
linux kernel. So how can I prevent the tools or xend of using the
balloon
driver??
Mit freundlichen Grüßen / Best Regards
Christian Kaiser
--
IBM Deutschland Entwicklung GmbH
Open Systems Firmware Development
mail: [EMAIL PROTECTED]
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
[EMAIL PROTECTED] wrote on 09/24/2007
04:03:01 PM:
Hi all,
I tried to build xen on a JS21 blade today but some hints at the
build
page
(http://wiki.xensource.com/xenwiki/XenPPC/Build) are confusing me.
The wiki says clone this:
http://xenbits.xensource.com/ext/ppc/xen-unstable.hg;
But later it is two times mentioning the xenppc-unstable tree.
So was there a switch from xenppc-unstable to xen-unstable??
Which repository should be used to build the hypervisor?
The xen-unstable tree cannot be build on my machine. I get the
following
error:
gcc -O2 -fomit-frame-pointer -DELFSIZE=64 -DNDEBUG -fno-strict-
aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement -m64 -ffreestanding -fno-builtin
-fno-common
-iwithprefix include -Werror -pipe
-I/root/xen/xen-unstable.hg/xen/include
-I/root/xen/xen-unstable.hg/xen/include/asm-powerpc/mach-generic
-I/root/xen/xen-unstable.hg/xen/include/asm-powerpc/mach-default
-Wredundant-decls -Wpacked -msoft-float -O2 -g -D__XEN__ -c
domain.c -o
domain.o
cc1: warnings being treated as errors
In file included from domain.c:22:
/root/xen/xen-unstable.hg/xen/include/xen/hypercall.h:117: warning:
redundant redeclaration of ‘do_xsm_op’
/root/xen/xen-unstable.hg/xen/include/xsm/xsm.h:24: warning: previous
declaration of ‘do_xsm_op’ was here
make[3]: *** [domain.o] Error 1
make[3]: Leaving directory `/root/xen/xen-unstable.hg/xen/common'
make[2]: *** [/root/xen/xen-unstable.hg/xen/common/built_in.o]
Error 2
make[2]: Leaving directory `/root/xen/xen-unstable.hg/xen/arch/
powerpc'
make[1]: *** [/root/xen/xen-unstable.hg/xen/xen] Error 2
make[1]: Leaving directory `/root/xen/xen-unstable.hg/xen'
make: *** [build] Error 2
make: Leaving directory `/root/xen/xen-unstable.hg/xen'
After omitting -Werror in xen/arch/powerpc/Rules.mk I get this
error:
gcc -O2 -fomit-frame-pointer -DELFSIZE=64 -DNDEBUG -fno-strict-
aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement -m64 -ffreestanding -fno-builtin
-fno-common
-iwithprefix include -pipe -I/root/xen/xen-unstable.hg/xen/include
-I/root/xen/xen-unstable.hg/xen/include/asm-powerpc/mach-generic
-I/root/xen/xen-unstable.hg/xen/include/asm-powerpc/mach-default
-Wredundant-decls -Wpacked -msoft-float -O2 -g -D__XEN__ -Wundef
-Wmissing-prototypes -Wmissing-declarations -Wshadow -nodefaultlibs
-nostartfiles -Wl,--omagic -Wl,-T,xen.lds start.o
/root/xen/xen-unstable.hg/xen/common/built_in.o
/root/xen/xen-unstable.hg/xen/drivers/built_in.o
/root/xen/xen-unstable.hg/xen/xsm/built_in.o
/root/xen/xen-unstable.hg/xen/arch/powerpc/built_in.o
/root/xen/xen-unstable.hg/xen/common/symbols-dummy.o -o .xen-syms
/root/xen/xen-unstable.hg/xen/arch/powerpc/built_in.o: In function
`do_physdev_op':
../x86/physdev.c:94: undefined reference to `xsm_apic'
../x86/physdev.c:77: undefined reference to `xsm_apic'
../x86/physdev.c:112: undefined reference to `xsm_assign_vector'
/root/xen/xen-unstable.hg/xen/arch/powerpc/built_in.o: In function
`__start_xen':
/root/xen/xen-unstable.hg/xen/arch/powerpc/setup.c:353: undefined
reference
to `acm_init'
/root/xen/xen-unstable.hg/xen/arch/powerpc/built_in.o: In function
`__hypercall_table':
(.data+0x2e1278): undefined reference to `do_acm_op'
collect2: ld returned 1 exit status
make[2]: *** [.xen-syms] Error 1
make[2]: Leaving directory `/root/xen/xen-unstable.hg/xen/arch/
powerpc'
make[1]: *** [/root/xen/xen-unstable.hg/xen/xen] Error
Re: [XenPPC] DOM0 can not be set up
On Aug 9, 2007, at 9:56 PM, Jun Hui Bu wrote: Hello, 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! I think it is you yaboot.conf (XEN) Dom0 has maximum 2 VCPUs (XEN) elf_init: not an ELF binary This is the key. yaboot.conf: --- image = /boot/xen label = xen root = /dev/disk/by-id/ata-TOSHIBA_MK4019GAXB_93SK3653T-part3 initrd = /boot/zImage.initrd ahh.. Xen will high-jack the initrd from yaboot and consider it as the dom0 image. so you could have image = /boot/xen label = xen root = /dev/disk/by-id/ata-TOSHIBA_MK4019GAXB_93SK3653T-part3 initrd = /boot/vmlinux-2.6.16.46-0.12-ppc64 assuming that this kernel is Xen capable. but then you would have needed an initrd from somewhere. This is a limitation of yaboot for Xen. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] 64bit apps in DomU should get a more useful error message [Fixed]
On Jul 10, 2007, at 9:22 AM, Christian Ehrhardt wrote: Jimi Xenidis wrote: Now Executed in a xenppc DomU ./hellobit.32 Hello World! ./hellobit.64 -bash: ./hellobit.64: No such file or directory hmm.. this works just fine for me and should have nothing to do with Xen at all, unless your block device does not work :) can you cat it? ls it? file it? Yes I can (tested it already). Hollis suggested that there may be some compat libraries missing but I did not find an obvious one missing. And thats right, some links in /lib64 were broken while I created the DomU image files from my Dom0 some months ago. I should never trust rpm -qa without checking file existence ;-) ahh I see, so the No such file or directory refers to /lib64/ ld64.so.1 which is the interpreter for the dynamic executable? $ objdump -s -j .interp hellobit.64 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] 64bit apps in DomU should get a more useful error message
On Jul 9, 2007, at 7:47 AM, Christian Ehrhardt wrote:
Example:
#include stdio.h
main()
{
printf (Hello World!\n);
}
Compiled (on Dom0):
gcc -m32 hellobit.c -o hellobit.32
gcc -m64 hellobit.c -o hellobit.64
Now Executed in a xenppc DomU
./hellobit.32
Hello World!
./hellobit.64
-bash: ./hellobit.64: No such file or directory
hmm.. this works just fine for me and should have nothing to do with
Xen at all, unless your block device does not work :)
can you cat it? ls it? file it?
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add #ifdef ARCH_HAS_DEV_MEM to archtecture specific file_operations.
On Jul 9, 2007, at 3:41 PM, Hollis Blanchard wrote: On Mon, 2007-07-09 at 20:26 +0100, Keir Fraser wrote: On 9/7/07 20:20, Hollis Blanchard [EMAIL PROTECTED] 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... :) yeah, we have :) xlate_dev_mem_ptr() works just fine for us, so drivers/char/mem.c just works and the xen version of the ops is never considered. Actually we should be forcing CONFIG_XEN_DEVMEM, but the Makefile ignores it. -JX ___ 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?
On Jun 18, 2007, at 3:19 PM, James Bulpin wrote: 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? Oh that would be awesome! -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] dom0 auto-translate mmap()
BTW: there was a quick discussion on this before:
http://lists.xensource.com/archives/html/xen-devel/2006-11/
msg00672.html
IIRC, We we continued faking it out until we got the ability to
mmap'ing arbitrary pages.
Now that we fixed the ability to properly address remote memory,
this should be easy enough.
-JX
On Jun 11, 2007, at 12:42 PM, Hollis Blanchard wrote:
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
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Why no do_softirq() after external interrupt ?
Yes, I agree, it is strange and could be coded either way. I doubt there was any real intent here, is is simply how we coded it. The 970 (our only port) has issues with external interrupt latencies already, I doubt this code really effects performance. At the moment we share control if the PIC with Dom0 which we are trying to get away from with the newer kernels so once we have achieved this de-coupling we did plan on revisiting this code path. I would be happy to take a patch that changed this, especially if you could demonstrate that it results in lower-latency for interrupts. -JX On May 17, 2007, at 9:03 PM, HYEONSEUNG JANG wrote: There are currently three places in xen code where do_softirq() is called. - return to the guest from the hypervisor decrementer interrupt handler - return to the guest from a hypercall() - in idle_loop() But it is kind of strange that do_softirq() is not called after external interrupt handler, ex_external_continued: EXCEPTION_SAVE_STATE r1 LOADADDR r12, do_external mr r3, r1 /* pass pointer to cpu_user_regs */ subi r1, r1, STACK_FRAME_OVERHEAD /* make a caller stack frame */ CALL_CFUNC r12 addi r1, r1, STACK_FRAME_OVERHEAD /* restore stack to cpu_user_regs */ b fast_resume This can cause quite large delay in interrupt processing because context switching is done by SCHEDULE_SOFTIRQ. For example, Let's assume that domU is now running and there is an external interrupt. - domU is interrupted and Xen's do_external() is called - an event channel toward dom0 is set to 'pending' - domU is resumed by fast_resume - dom0 is never scheduled even if it has the higher priority until do_softirq() is called by the next hyperviosr decrementer interrupt. When I look at the same parts for the x86 arch, it seems that softirq is processed in every 'ret_from_int' which, I think, is expected behaviour. Is there anyone who can tell me the reason why do_softirq() is not called after external interrupt handling? Or is it just a simple missing(but important) code in XenPPC port ? - HyeonSeung Jang.___ 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] Status of CoW on xenppc based on blktap - could someone reproduce my issue?
On May 17, 2007, at 10:33 AM, Hollis Blanchard wrote: It looks like blktap is a loadable kernel module, and you don't have it loaded? On Wed, 2007-05-16 at 13:43 +0200, Christian Ehrhardt wrote: So, the question is - why is there no /sys/class/[xen| misc]/blktap0/dev ? Actually.. we never brought it over into our xenolinux. It is in the newer repo that we are playing with, so it should be available soon. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Question on CellBE, PS3, etc.
On Apr 12, 2007, at 9:51 AM, Fang Zhe wrote: Hi, all I'm wondering if XenPPC can work on Cell BE(As it includes a 970 compatiable Core), Yes, it could work on Cell with not a whole lot of effort. Some register remappings, IIC and IOMMU work and you'd get just about everything else for free. and ...what about PS3? Is it possible? PS3 already comes with Sony's Hypervisor, so unless you can get _it_ out of the way, it would take substantially more work and it would be similar to the noHV work that was done for G5s: http://wiki.xensource.com/xenwiki/XenPPC/NoHV Or anybody already working on it? nope, but I know quite a bit about Cell and would be willing to help. -JX ___ Xen-ppc-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Fix xchg api to for Xen-unstable
On Apr 4, 2007, at 10:43 PM, Jerone Young wrote:
On Wed, 2007-04-04 at 08:57 -0400, Jimi Xenidis wrote:
hmm, how did this ever work?!
I your problem with a direct caller of __xchg() or is this thru the
macro xchg()?
The caller is in common/domain.c @ line 310:
/* Already dying? Then bail. */
if ( xchg(d-is_dying, 1) )
{
domain_unpause(d);
return;
}
The current macro matches that one in x86. But the parameters we have
for __xchg are not in the same order. So one has to change to be
right.
I notice we have the macro wrong (at least in my copy of xen source):
#define xchg(ptr,v) ((__typeof__(*(ptr)))__xchg((unsigned long)
(v),
(ptr),sizeof(*(ptr
where it should be (from Linux):
#define xchg(ptr,x) \
({\
__typeof__(*(ptr)) _x_ = (x); \
(__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_, sizeof(*
(ptr))); \
})
Will that change fix your issue?
Doubtful..see use of code above.
Why?
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Fix xchg api to for Xen-unstable
hmm, how did this ever work?!
I your problem with a direct caller of __xchg() or is this thru the
macro xchg()?
I notice we have the macro wrong (at least in my copy of xen source):
#define xchg(ptr,v) ((__typeof__(*(ptr)))__xchg((unsigned long)(v),
(ptr),sizeof(*(ptr
where it should be (from Linux):
#define xchg(ptr,x)\
({ \
__typeof__(*(ptr)) _x_ = (x); \
(__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_, sizeof(*
(ptr))); \
})
Will that change fix your issue?
I'd rather not change __xchg().
-JX
On Apr 4, 2007, at 2:04 AM, Jerone Young wrote:
This fixes the api for __xchg function in system.h so that PPC Xen can
build correctly in Xen unstable. This is the same API used in the
__xchg
on x86.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 7e431ea834a8 xen/include/asm-powerpc/system.h
--- a/xen/include/asm-powerpc/system.h Tue Apr 03 13:22:37 2007 +0100
+++ b/xen/include/asm-powerpc/system.h Wed Jan 29 05:37:30 2031 -0600
@@ -73,7 +73,7 @@ extern void __xchg_called_with_bad_point
extern void __xchg_called_with_bad_pointer(void);
static __inline__ unsigned long
-__xchg(volatile void *ptr, unsigned long x, int size)
+__xchg(unsigned long x, volatile void *ptr, int size)
{
switch (size) {
case 4:
___
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] [PATCH] Remove uses of packed attribute so Xen-unstable will build
There was an agreement not to allow packed in common code. Could you sent this issue upstream and CC the author of the patch that introduced these? They should know better :) -JX On Apr 4, 2007, at 2:04 AM, Jerone Young wrote: So use of packed attribute is bad for PPC. PPC Xen build checks for this and will not build if this is in the code. Signed-off-by: Jerone Young [EMAIL PROTECTED] fix_acm.h ___ 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] Status and supported hardware?
On Apr 1, 2007, at 2:38 PM, Andreas Barth wrote: Hi, I'm interessted in finding out whether Xen runs on my powerpc. We only support PowerPC 970 CPUs. Sadly, I didn't find a page that tells me what the current state of the powerpc support is, and which hardware is supported (or does that mean that even experienced end-users should keep distance currently?). You can track our status here: http://wiki.xensource.com/xenwiki/XenPPC I would be happy for any pointer to such a page (and perhaps a more prominent location, like mentioned in the signature of this list), and perhaps someone could give me a hint whether my box is supported: revision: 0.1 (pvr 8002 0101) I believe that the major codes = 8000 are all Motorola/Freescale chips, so I'm afraid the current source does not support this at all. platform: CHRP machine : CHRP Pegasos2 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] What does the PAPR macro?
On Mar 28, 2007, at 2:39 PM, Christian Ehrhardt wrote: Hi, I'm curently implementing H_PERFMON and found some code in the file arch/powerpc/of_handler/papr.S which is not clear for me by just reading it ;) This is code for the OF stub that we but in Dom0 address space, it usually only needs to perform console hcalls, there is no reason to add the H_PERFMON hcall to this code, this code runs in a domain NOT Xen. I guessed this line together for H_PERFMON based on the other lines around there, but what would the following line really do? PAPR(5, 1,papr_h_perfmon, H_PERFMON) This will create a C callable function (papr_h_perfmon) written in assembler that for an hcall that takes 5 arguements and returns a single result value. Is it correct and if not why? It is correct, but unecessary, please do not bother. I assume it's some kind of registering xen implemented papr hooks right? Nope -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Location to hook setting ppc_md.enable_pmcs for xen
On Mar 27, 2007, at 6:57 AM, Christian Ehrhardt wrote: How does the inclusion of the code in the subdir platform/xen work in xenppc-linux - Does it replace the bare metal code in platform/ pseries or does it extend it in any way? Please go with option (b). Until we actually merge with upstream we try to keep non-xen code changes to a minimum. It means duplicating some code, but that is ok. Xen has has at least a completely own define_machine section there so I assume replace. The issue is that I ask myself if I should add something like: a) in function pSeries_setup_arch of arch/powerpc/platforms/ pseries/setup.c ... + if (?XEN?) + ppc_md.enable_pmcs = pseries_xen_enable_pmcs; m else if (firmware_has_feature(FW_FEATURE_LPAR)) ppc_md.enable_pmcs = pseries_lpar_enable_pmcs; else ppc_md.enable_pmcs = power4_enable_pmcs; ... or b) go to the xen path and do this in function xen_setup_arch of arch/powerpc/platforms/xen/setup.c with something like this: ... xen_setup_smp(); #endif +ppc_md.enable_pmcs = pseries_xen_enable_pmcs; printk(KERN_INFO Using Xen idle loop\n); ... According to the Makefile of arch/powerpc/plattforms both are build anyway. As far as I read it in the code the platform is detected at boot time and the appropriate ppc_md structure gets selected which should be the only xen structure in our case. This would argue for variant b) to implement it in arch/powerpc/ platforms/xen/* Can someone with more experience in that area please send an ack for b) or correct me? -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization +49 7031/16-3385 [EMAIL PROTECTED] [EMAIL PROTECTED] IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ 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] performance profiling current and future steps
On Mar 26, 2007, at 8:26 AM, Christian Ehrhardt wrote: Jimi Xenidis wrote: On Mar 23, 2007, at 9:07 AM, Hollis Blanchard wrote: Right, that won't fit in EXCEPTION_HEAD (you will get the assembler error messages Jimi pasted above). Yeah, So EXCEPTION_HEAD branches to a passed in label. Find all those labels and insert PMU_SAVE_STATE there. I need a register to clobber with my ori. (H_) EXCEPTION_SAVE_STATE clobbers r0 anyway and it resides in all continue labels that are passed to EXCEPTION_HEAD. So PMU_SAVE_STATE can follow in its wake and clobber r0 too like EXCEPTION_SAVE_STATE. branches to EXCEPTION_HEAD: xenppc-unstable_step1/xen# cat arch/powerpc/powerpc64/ exceptions.S | grep EXCEPTION_HEAD | sort | uniq EXCEPTION_HEAD r13 ex_dec_continued EXCEPTION_HEAD r13 ex_external_continued EXCEPTION_HEAD r13 ex_hcall_continued EXCEPTION_HEAD r13 ex_hdec_continued EXCEPTION_HEAD r13 ex_machcheck_continued EXCEPTION_HEAD r13 ex_program_continued One of those calls as example diff -Naur: @@ -384,6 +391,7 @@ mr r14, r0 EXCEPTION_SAVE_STATE r1 +PMU_SAVE_STATE r0,r0 mr r4, r14 LOADADDR r12, program_exception mr r3, r1 /* pass pointer to cpu_user_regs */ Please correct me If my assumption is wrong that I'm allowed to clobber r0 there. After EXCEPTION_SAVE_STATE r0 and r3-r12 are fair game, so yeah, r0 is fine. r1 points to your save area so I'd use PMU_SAVE_STATE r0, r1, the macro does not save any state, but it will one day. You should also from the second argument (r1) until you have a patch that actually needs it. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Next profiling clarification question
On Mar 20, 2007, at 11:36 AM, Hollis Blanchard wrote: On Mon, 2007-03-19 at 15:30 +0100, Christian Ehrhardt wrote: Hi, I have one more questions regarding the oprofile extension to work in xenppc guests. The plain linux implementation sets !always! the vector for the performance interrupt 0xf00 to the function performance_monitor_exception in head32.S/head64.S. Depending on wether linux starts profiling this function is set to a dummy or the real handler of e.g. oprofile. Now in the virtualized environment each guest set's its own interrupt handler for 0xf00 (Performance monitor interrupt). Yes, each guest decided to set it to a dummy or a real handler. Because we are running with LPSE[1]=0 as Jimi wrote before the performance interrupt while a Dom is running should be handled from the domain because nothing sets MSR[HV] to 1. OK, so performance monitor interrupts go directly to the guest. My question is now if the address translation virtualization ensures that each perf interrupt will be a) served by the right function adress and b) in the domain. Maybe there is some exclusive part involved and the different writes of the 0xf00 vector may overwrite each other or something similar - that's why I want to ask to be sure. On this architecure, all interrupts turn translate off, MSR[IR|DR] =0b00. The hypervisor design provided by using LPES[0]=1 allows us to create an area that the domain can consider translate off we call this the Real Mode Area (RMA) and each RMA must be unique to every guest. So each guest is free to install its own unique interrupt handlers, since any interrupts that do not modify MSR[HV] will cause the the CPU to execute at the same effective address offset into the RMA. Example of a system with two DomU guests that enabled the performance counters. Running: Xen 0xf00 - undef? I'm not sure what to do about a perfmon interrupt in Xen. Since we're saving/restoring the perfmon register state on domain entry/exit, can we just disable those interrupts while running Xen? Yes with MMCR0[HFC] Dom0 0xf00 - default_pmc_irq DomU1 0xf00 -pmc_irq_handler1 DomU2 0xf00 -pmc_irq_handler2 I don't understand the question about translation. The domains do not share code. For example, it is not possible for an interrupt in Dom1 to trigger an exception handler in Dom0. I think the Christian believes all domains share the same interrupt vectors, I hope the RMA discussion has clarified that. -JX ___ 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
ok, I am confused, and not sure I care until I see the patch that fives the result you want. -JX On Feb 27, 2007, at 5:19 PM, Hollis Blanchard wrote: 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] Should the platform name be Xen-Maple
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 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 3 of 6] [PATCH] xen: implement guest_physmap_max_mem for ppc
On Feb 22, 2007, at 5:07 PM, Ryan Harper wrote:
* Hollis Blanchard [EMAIL PROTECTED] [2007-02-22 15:01]:
On Wed, 2007-02-21 at 18:17 -0500, Ryan Harper wrote:
4 files changed, 72 insertions(+)
xen/arch/powerpc/domain.c| 60 ++
xen/arch/powerpc/domain_build.c |5 +++
xen/include/asm-powerpc/domain.h |3 +
xen/include/asm-powerpc/shadow.h |4 ++
# HG changeset patch
# User Ryan Harper [EMAIL PROTECTED]
# Date 1172103252 21600
# Node ID 35fd77200dff7e73fe3959b5dbfa6088c691c502
# Parent 84ec1b4d5cd50cc9d49202eb978a4715c4780e28
[PATCH] xen: implement guest_physmap_max_mem for ppc
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
diff -r 84ec1b4d5cd5 -r 35fd77200dff xen/arch/powerpc/domain.c
--- a/xen/arch/powerpc/domain.c Wed Feb 21 18:14:12 2007 -0600
+++ b/xen/arch/powerpc/domain.c Wed Feb 21 18:14:12 2007 -0600
@@ -33,6 +33,7 @@
#include asm/htab.h
#include asm/current.h
#include asm/hcalls.h
+#include asm/shadow.h
#include rtas.h
#include exceptions.h
@@ -347,3 +348,62 @@ void idle_loop(void)
do_softirq();
}
}
+
+int do_guest_physmap_max_mem(struct domain *d, unsigned long
new_max)
Could you rename new_max to new_max_pages so we can keep the
units
straight? (I know they use new_max in the XEN_DOMCTL_max_mem
handler.)
Yep.
+{
+ulong *p2m_array = NULL;
+ulong *p2m_old = NULL;
+ulong p2m_pages;
+ulong copy_end = 0;
+
+/* we don't handle shrinking max_pages */
+if ( new_max d-max_pages )
+{
+printk(Can't shrink %d max_mem\n, d-domain_id);
+return -EINVAL;
+}
We won't be called in this case, so this test can be removed.
OK.
+/* our work is done here */
+if ( new_max == d-max_pages )
+return 0;
+
+/* check new_max pages is 16MiB aligned */
+if ( new_max ((112)-1) )
+{
+printk(Must be 16MiB aligned increments\n);
+return -EACCES;
+}
The 16MB thing is because the 970's large page size is 16MB, and the
kernel uses large pages to map its text. That said, I don't see
why this
should be enforced by Xen when setting max_mem (if ever).
Stylistically,
I also object to the literals used here.
Great. I told myself that I was going to replace the literals since I
was guessing that there might be a common check like cpu_aligned().
+/* make a p2m array of new_max mfns */
+p2m_pages = (new_max * sizeof(ulong)) PAGE_SHIFT;
+/* XXX: could use domheap anonymously */
+p2m_array = alloc_xenheap_pages(get_order_from_pages
(p2m_pages));
It is a shame that these pages will be naturally aligned, which is
unecessary.
+if ( p2m_array == NULL )
+return -ENOMEM;
I think the Xen heap is on the small side. Do you have an idea of how
much memory we have available? I suppose we can change it later if we
exhaust the heap.
In the later heap mail-thread I suggest that you add nr_pages*sizeof
(p2m_pages[]) to the xenheap calculation, that will make sure the
xenheap is a good size.
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?
We had talked about using ints for the p2m array, since that would
only
limit us to 44 bits of physical memory. Did you decide to use longs
instead?
No, just being lazy. I wanted to get the patches out for comment ASAP
but I forgot to note that we were going to use u32 in the mails. I
still plan to switch p2m array to smaller size.
+/* copy old mappings into new array if any */
+if ( d-arch.p2m != NULL )
+{
+/* mark where the copy will stop (which page) */
+copy_end = d-max_pages;
+
+/* memcpy takes size in bytes */
+memcpy(p2m_array, d-arch.p2m, (d-max_pages * sizeof
(ulong)));
+
+/* keep a pointer to the old array */
+p2m_old = d-arch.p2m;
+}
This memcpy could be pretty slow; might be better if we could make
this
a continuation some day. If you agree, could you add a comment to
that
effect?
Good point.
And in that case it should be a copy_page() loop.
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 1 of 6] [PATCH] xen: add arch hook for max_mem hcall
On Feb 21, 2007, at 6:16 PM, Ryan Harper wrote: 2 files changed, 6 insertions(+) xen/common/domctl.c |4 xen/include/xen/shadow.h |2 ++ NIT: I think mm.h or domain.h is a better home for the macro/proto. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: xen heap size
We don't consider the RMA boundary for the Xen heap at all anymore (not for a while) The Xen heap is calculated based on the estimated resources we'll need. on example is that we need to get enough HTABs for all the domain, so 1/64th of all of memory is part of the Xen heap size. check out powerpc/memory.c: memory_init() On Feb 22, 2007, at 5:28 PM, Hollis Blanchard wrote: 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 ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] domain physical to machine address translation
nice, some comments. On Feb 14, 2007, at 11:54 AM, Hollis Blanchard wrote: 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. Is domain-p2m that array? Why pointers, you can decrease the array size if you keep it full of MFNs (which are u32s) which is good to 16TiB * increase_reservation() calls guest_physmap_add_page() with domain, pfn, and mfn. domain-p2m[pfn] = mfn_to_page(mfn) domain-p2m[pfn] = mfn * decrease_reservation() calls guest_physmap_remove_page() with the same parameters. domain-p2m[pfn] = NULL domain-p2m[pfn] = INVALID_MFN What is the locking model? IIRC it is possible to increase (but not decrease?) maxmem, so that would be an alloc, copy, free? Will you allow increases that are not multiple of 16MiB of our current extents? Should we (trivially) teach linux not to use large pages to allow maximum freedom (after RMA)? It would actually reduce our linux patch. 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 Thoughts, on the 970 if you have more than 2GiB of memory then your frame_table will actually contain the IO area. In order to * drastically improves performance for accessing high addresses in large domains (avoids the extent list walk) Agreed! * 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, 1/512th.. please respect the powers of 2 :) e.g. a 1GB domain would require a 2MB array. Moving to MFNs drops that down to 1MB This memory would probably need to be allocated from the domain heap to avoid exhausting the Xen heap. I'd like to avoid messing up the domain heap, nothing is worse than having a lot of free memory no space that can be used for RMA. Since the needs of these arrays are quite predicable, 1 p2m[] entry for every mfn, we could accommodate for that in the Xen heap like we do for HTABs. We don't need to use an array long-term, though I think it's the easiest initial implementation. agreed. The simplest version of this patch would just replace the RMA and extent list walking in pfn2mfn(), so it's nothing radical. nice. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] domain physical to machine address translation
On Feb 14, 2007, at 1:30 PM, Jimi Xenidis wrote: nice, some comments. On Feb 14, 2007, at 11:54 AM, Hollis Blanchard wrote: Thoughts, on the 970 if you have more than 2GiB of memory then your frame_table will actually contain the IO area. In order to s/In order to// ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Fix up potential memory leaks introduced by xencomm patch
mostly Linux Kernel style NITS
On Feb 7, 2007, at 4:26 PM, Jerone Young wrote:
With some of the logic change from the Xencomm patch. In a few
hypercalls introduces a situation where you can potentially have
memory
leaks if something fails. This patch address these issues.
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff -r 37ea4cf1281a arch/powerpc/platforms/xen/hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Tue Feb 06 17:10:20 2007
-0500
+++ b/arch/powerpc/platforms/xen/hcall.c Wed Feb 07 14:50:05 2007
-0600
@@ -203,11 +203,16 @@ int HYPERVISOR_sched_op(int cmd, void *a
desc = xencomm_map_no_alloc(arg, argsize);
- if (desc == NULL)
- return -EINVAL;
-
- rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
- cmd, desc);
+ if (desc)
+ {
brace on same line
+ rc = plpar_hcall_norets(XEN_MARK(__HYPERVISOR_sched_op),
+ cmd, desc);
+ xencomm_free(desc);
+ }
+ else
+ {
no braces for single line, in fact avoid the single line by pre-
assigning the rc, the compiler will do the right optimization anyway.
+ rc = -EINVAL;
I thought we agreed that xencomm_map_* failures would be ENOMEM or
ENOSPC?
+ }
xencomm_free(ports);
@@ -389,8 +394,8 @@ static int xenppc_privcmd_domctl(privcmd
if (copy_to_user(user_op, kern_op, sizeof(xen_domctl_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -463,8 +468,8 @@ static int xenppc_privcmd_sysctl(privcmd
if (copy_to_user(user_op, kern_op, sizeof(xen_sysctl_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -514,8 +519,8 @@ static int xenppc_privcmd_platform_op(pr
if (copy_to_user(user_op, kern_op, sizeof(xen_platform_op_t)))
ret = -EFAULT;
- xencomm_free(desc);
out:
+ xencomm_free(desc);
xencomm_free(op_desc);
return ret;
}
@@ -547,7 +552,10 @@ int HYPERVISOR_memory_op(unsigned int cm
sizeof(*xen_guest_handle(mop-extent_start)));
if (desc == NULL)
+ {
Curlies again
+ xencomm_free(op_desc);
return -ENOMEM;
+ }
set_xen_guest_handle(mop-extent_start,
desc);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 2/2] linux: build start_info_t from devtree only
some comments
On Feb 7, 2007, at 6:34 PM, Ryan Harper wrote:
This patch cleans up xen_init_early() to construct a start_info_t only
from the devtree as Patch1 fixes xen to no longer create a
start_info_t
for dom0.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
setup.c | 33 +++--
1 files changed, 15 insertions(+), 18 deletions(-)
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
---
diff -r a6adf094e08e arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.c Tue Feb 06 13:55:48 2007
-0600
+++ b/arch/powerpc/platforms/xen/setup.c Wed Feb 07 11:33:10 2007
-0600
@@ -88,29 +88,26 @@ static void __init xen_init_early(void)
static void __init xen_init_early(void)
{
struct device_node *xen;
- u64 *si;
DBG( - %s\n, __func__);
xen = of_find_node_by_path(/xen);
- si = (u64 *)get_property(xen, start-info, NULL);
-
- /* build our own start_info_t if start-info property is not
present */
- if (si != NULL) {
- xen_start_info = (start_info_t *)__va(*si);
- } else {
- struct device_node *console;
- struct device_node *store;
-
- console = of_find_node_by_path(/xen/console);
- store = of_find_node_by_path(/xen/store);
-
- xen_start_info = xsi;
-
- /* fill out start_info_t from devtree */
- xen_start_info-shared_info = *((u64 *)get_property(xen,
- shared-info, NULL));
+ xen_start_info = xsi;
Please make xsi static in its declaration earlier in the file.
+
+ /* fill out start_info_t from devtree */
+ if ((char *)get_property(xen, privileged, NULL))
+ xen_start_info-flags |= SIF_PRIVILEGED;
+ if ((char *)get_property(xen, initdomain, NULL))
+ xen_start_info-flags |= SIF_INITDOMAIN;
+ xen_start_info-shared_info = *((u64 *)get_property(xen,
+ shared-info, NULL));
+
+ /* only look for store and console for guest domains */
Hmm, I think you need to look for them always.
You _at_least_ need the console evtchn, which may not be zero and we
create the node/prop anyway.
Feel free to panic() more:
NOTE: this is early so a udbg_printf(); HYPERVISOR_shutdown
(SHUTDOWN_poweroff); will do cuz panic() is no available yet.
if (!store !(xen_start_info-flags | SIF_INITDOMAIN) panic();
if (!console) panic();
if (get_property(console, reg, NULL) == NULL
!(xen_start_info-flags | SIF_INITDOMAIN)) panic
+ if (xen_start_info-flags == 0) {
+ struct device_node *console =
of_find_node_by_path(/xen/console);
+ struct device_node *store = of_find_node_by_path(/xen/store);
+
xen_start_info-store_mfn = (*((u64 *)get_property(store,
reg, NULL))) PAGE_SHIFT;
xen_start_info-store_evtchn = *((u32 *)get_property(store,
___
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] [PATCH 2/2] linux: build start_info_t from devtree only
On Feb 8, 2007, at 8:45 AM, Ryan Harper wrote:
* Jimi Xenidis [EMAIL PROTECTED] [2007-02-08 06:48]:
some comments
On Feb 7, 2007, at 6:34 PM, Ryan Harper wrote:
This patch cleans up xen_init_early() to construct a start_info_t
only
from the devtree as Patch1 fixes xen to no longer create a
start_info_t
for dom0.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
setup.c | 33 +++--
1 files changed, 15 insertions(+), 18 deletions(-)
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
---
diff -r a6adf094e08e arch/powerpc/platforms/xen/setup.c
--- a/arch/powerpc/platforms/xen/setup.cTue Feb 06 13:55:48 2007
-0600
+++ b/arch/powerpc/platforms/xen/setup.cWed Feb 07 11:33:10 2007
-0600
@@ -88,29 +88,26 @@ static void __init xen_init_early(void)
static void __init xen_init_early(void)
{
struct device_node *xen;
- u64 *si;
DBG( - %s\n, __func__);
xen = of_find_node_by_path(/xen);
- si = (u64 *)get_property(xen, start-info, NULL);
-
- /* build our own start_info_t if start-info property is not
present */
- if (si != NULL) {
- xen_start_info = (start_info_t *)__va(*si);
- } else {
- struct device_node *console;
- struct device_node *store;
-
- console = of_find_node_by_path(/xen/console);
- store = of_find_node_by_path(/xen/store);
-
- xen_start_info = xsi;
-
- /* fill out start_info_t from devtree */
- xen_start_info-shared_info = *((u64 *)get_property(xen,
- shared-info, NULL));
+ xen_start_info = xsi;
Please make xsi static in its declaration earlier in the file.
Sure. And while I wanted to access xsi vai xen_start_info,
the
xen_start_info = xsi
seemed a bit awkward. Not sure if I should switch to xsi. Thoughts?
There is too much code referring to xen_start_info as a pointer.
perhaps making that static __xen_start_info, so its obvious that we
are just suing it for memory allocation, at some point when all
references are gone we can flatten this out.
+
+ /* fill out start_info_t from devtree */
+ if ((char *)get_property(xen, privileged, NULL))
+ xen_start_info-flags |= SIF_PRIVILEGED;
+ if ((char *)get_property(xen, initdomain, NULL))
+ xen_start_info-flags |= SIF_INITDOMAIN;
+ xen_start_info-shared_info = *((u64 *)get_property(xen,
+ shared-info, NULL));
+
+ /* only look for store and console for guest domains */
Hmm, I think you need to look for them always.
You _at_least_ need the console evtchn, which may not be zero and we
create the node/prop anyway.
Hrm, you may be right. I know that dom0 boots fine with this, but
that
maybe because it defaults those values to 0. I'll kill the if().
Feel free to panic() more:
NOTE: this is early so a udbg_printf(); HYPERVISOR_shutdown
(SHUTDOWN_poweroff); will do cuz panic() is no available yet.
Yeah, good idea though none of the messages get out if our shared_info
page isn't setup correctly, which I learned during my testing of this
patch, was the value most likely to get hosed.
Oh yeah, you probably want to:
HYPERVISOR_shared_info = ...;
xen_start_info-flags |= SIF_INITDOMAIN; # or not
udbg_init_xen();
As soon as you can, before you check everything else.
If you want more info earlier you can always build with:
CONFIG_PPC_EARLY_DEBUG_XEN_DOM0
xor
CONFIG_PPC_EARLY_DEBUG_XEN_DOMU
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] [UPDATE] Xencomm patch
pushed.. thanks On Feb 5, 2007, at 5:42 PM, Jerone Young wrote: Yes..another Xencomm patch :-). The last one actually hit a bug that was currently in xen-linux with handling of domain control operation XEN_DOMCTL_shadow_op. This fix is included in the patch. I've also added error handling and changed return codes from xencomm_no_alloc() failure to be EINVAL. Signed-off-by: Jerone Young [EMAIL PROTECTED] xencomm.patch ___ 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] Problems with Xen in hg tree
On Feb 7, 2007, at 12:48 PM, Jerone Young wrote: OK all is well...no fire here...move along. I figured out what happened. I included the vmlinux as the DOM0_IMAGE and not the zImage. It compiled through .. it is a bit surprising the Xen died though and not during loading of Dom0. So ultimately this is a USER error ;-) Thats not user error, that should work, its not smart but is should work, stripped or not stripped. So vmlinux can be like 64M which is bigger that our boo_of allocator can currently handle. This is our bug, we should simply exit gracefully. Jerone, could you file a bug with the specifics? -JX ___ 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
On Feb 7, 2007, at 5:38 PM, Hollis Blanchard wrote: 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. Thats not really true, dom0 is in .data, there are actually additional objects that will get linked in after dom0, especially the init data and bss, so if the load is partial then who knows WTF will happen. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Problems with Xen in hg tree
On Feb 7, 2007, at 5:41 PM, Jerone Young wrote: On Wed, 2007-02-07 at 17:37 -0500, Jimi Xenidis wrote: On Feb 7, 2007, at 12:48 PM, Jerone Young wrote: OK all is well...no fire here...move along. I figured out what happened. I included the vmlinux as the DOM0_IMAGE and not the zImage. It compiled through .. it is a bit surprising the Xen died though and not during loading of Dom0. So ultimately this is a USER error ;-) Thats not user error, that should work, its not smart but is should work, stripped or not stripped. So vmlinux can be like 64M which is bigger that our boo_of allocator can currently handle. This is our bug, we should simply exit gracefully. Jerone, could you file a bug with the specifics? I can though adding a check to try and catch the size (as suggested by Hollis) does not look like it got far enough in the code to catch it. I think it's the tftp limit being 64MB (though I could be wrong). I'll file a bug never the less. If this is indeed a tftp limit than it is a SLOF bug. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] [RESEND] Xencomm patch
On Feb 2, 2007, at 7:10 PM, Jerone Young wrote: Sorry guys. Please ignore this patch. I found a bug with it. Will submit a fixed version shortly. Ok, took a peek though and it seems that not all xencomm_map*() calls have there return values checked. Using ENOSPC for the errno for xencomm_map_no_alloc() seems inappropriate, since it ENOSPC is really about devices. ENOMEM is not right because we are not trying to allocate. I do not think anything fits perfectly, but I'd go with EINVAL because argsize is simply to big and an invalid argument. Thoughts? -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] basic Xen achitecture question
On Feb 1, 2007, at 4:07 PM, Yoder Stuart-B08248 wrote: I'm trying to understand the paravirtualization interface between the OS and Xen. Here is one thing that's confusing me-- In Linux, the xen probe() routine calls hpte_init_lpar() which hooks up some pseries hypervisor MMU routines. These translate into a plpar_hcall_norets() invocation, but using pSeries hypervisor opcodes (e.g. H_PUT_TCE). Related to that I don't see the mmu_update hypercall used in Linux. How do the MMU related hypercalls work? We kept all the MMU and IOMMU related hcalls from PAPR, so the pSeries LPAR paths are jsut fine for us. The PAPR is availble from the power.org website. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Slab corruption
Thanks Ryan. This is dom0, and the last time I saw this was because we had the flat-tree reservations wrong in domu. I wonder if there is any howto's on debugging a slab corruption? -JX On Feb 1, 2007, at 4:18 PM, Ryan Harper wrote: I noticed the following output from the kernel running XenPPC on JS20, Slab corruption: start=c6d9f800, len=2048 680: a5 0c 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Prev obj: start=c6d9f000, len=2048 000: 30 30 2c 0a 30 78 30 30 30 30 30 30 30 30 2c 30 010: 78 30 30 30 30 30 30 30 30 2c 30 78 30 30 30 30 -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] ___ 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] [PATCH 1/4] move shared page definitions to public header
No need to respin, since this can wait for a follow-on/dom0 work, we
can lose:
+#define RMA_LAST_DOM0 2
+/* these are not used for dom0 so they should be last */
+#define RMA_CONSOLE 3
+#define RMA_STORE 4
+#define RMA_LAST_DOMU 4
Since dom0 does not use them, and
And when dom0 goes flat we can lose the rest.
The domU shared info page can be obtained from XEN_DOMCTL_getdomaininfo
Another option is that we could simply drop this patch all together
since the contents will go away.
-JX
On Jan 30, 2007, at 2:08 PM, Ryan Harper wrote:
Move shared page location contract to public header to share with
libxc.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
arch/powerpc/domain_build.c |1 +
arch/powerpc/mm.c |1 +
include/asm-powerpc/domain.h |7 ---
include/public/arch-powerpc.h |8
4 files changed, 10 insertions(+), 7 deletions(-)
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
---
diff -r 0980dfbae746 xen/include/asm-powerpc/domain.h
--- a/xen/include/asm-powerpc/domain.h Thu Jan 25 15:55:25 2007 -0500
+++ b/xen/include/asm-powerpc/domain.h Mon Jan 29 17:57:52 2007 -0600
@@ -107,13 +107,6 @@ extern void save_float(struct vcpu *);
extern void save_float(struct vcpu *);
extern void load_float(struct vcpu *);
-#define RMA_SHARED_INFO 1
-#define RMA_START_INFO 2
-#define RMA_LAST_DOM0 2
-/* these are not used for dom0 so they should be last */
-#define RMA_CONSOLE 3
-#define RMA_LAST_DOMU 3
-
#define rma_size(rma_order) (1UL ((rma_order) + PAGE_SHIFT))
static inline ulong rma_addr(struct arch_domain *ad, int type)
diff -r 0980dfbae746 xen/include/public/arch-powerpc.h
--- a/xen/include/public/arch-powerpc.h Thu Jan 25 15:55:25 2007 -0500
+++ b/xen/include/public/arch-powerpc.h Mon Jan 29 17:57:52 2007 -0600
@@ -117,6 +117,14 @@ struct arch_vcpu_info {
struct arch_vcpu_info {
};
+#define RMA_SHARED_INFO 1
+#define RMA_START_INFO 2
+#define RMA_LAST_DOM0 2
+/* these are not used for dom0 so they should be last */
+#define RMA_CONSOLE 3
+#define RMA_STORE 4
+#define RMA_LAST_DOMU 4
+
/* Support for multi-processor guests. */
#define MAX_VIRT_CPUS 32
#endif
diff -r 0980dfbae746 xen/arch/powerpc/domain_build.c
--- a/xen/arch/powerpc/domain_build.c Thu Jan 25 15:55:25 2007 -0500
+++ b/xen/arch/powerpc/domain_build.c Mon Jan 29 20:48:09 2007 -0600
@@ -30,6 +30,7 @@
#include xen/version.h
#include asm/processor.h
#include asm/papr.h
+#include public/arch-powerpc.h
#include oftree.h
extern int parseelfimage_32(struct domain_setup_info *dsi);
diff -r 0980dfbae746 xen/arch/powerpc/mm.c
--- a/xen/arch/powerpc/mm.c Thu Jan 25 15:55:25 2007 -0500
+++ b/xen/arch/powerpc/mm.c Mon Jan 29 20:47:39 2007 -0600
@@ -28,6 +28,7 @@
#include asm/init.h
#include asm/page.h
#include asm/string.h
+#include public/arch-powerpc.h
#ifdef VERBOSE
#define MEM_LOG(_f, _a...) \
___
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?
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? 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(). -JX On Jan 27, 2007, at 8:13 PM, Jerone Young wrote: I'm facing an interesting problem and I was wondering if anyone on the list (Jimi) could answer it. So in the xencomm patch that has been floating the list I have functions xencomm_map xencomm_map_early . Now currently they return physcial addresses regardless of the case. BUT, in the cases where they are not inline I face a BIG problem. As I have no way to truly translate back to a virtual address to free the memory with xencomm_free (__va() isn't going to cut it). So I currently have a patch (yet to go to the list) that has xencomm_map early returning a phyiscal address if it's inline and a virtual address if it is not. Well then I have a hack in xencomm_vtop that says if the address has bit XENCOMM_INLINE_FLAG. Then just return the address, since you are already physical. So when xencomm_pa() is used within the code it will return the proper address. Is this acceptable? I'm not sure of any other way of going about this since there is no good way to translate back to a virtual address to use xencomm_free. ___ 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] [PATCH 1/3] libxc: add start_info_t node to devtree
Thanks _a_lot_ Ryan.. this stuff is really tedious.
Just a few more things.
BTW: what about start_info-flags = SIF_PRIVILEGED or
SIF_INITDOMAIN. You will not need properties now but you will need
to make sure there absence is recognized in linux/.../setup.c.
On Jan 25, 2007, at 2:16 PM, Ryan Harper wrote:
* Jimi Xenidis [EMAIL PROTECTED] [2007-01-24 12:42]:
The data that was in start_info_t should be just simple bindings
in /
xen since they describe xen, there is no need to create a new node.
many of the props are not needed since they are expressed elsewhere
in the devtree or perhaps differently.
more below.
New rev:
-dropped /xen/start_info_t, hanging new node /xen/store
-fixed up /xen/console/reg to be proper u64 baseu64 size value
-fixed up /xen/console/interrupts to use value passed from xend
-renamed property 'shared_info' to 'shared-info'
-fixed 'shared-info' to be a proper u64 baseu64 size value
-reduced the number of pages reserved at the end of RMA from 4 to 3
as we no longer need to reserve a page for start_info_t
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
mk_flatdevtree.c | 45 +++--
mk_flatdevtree.h |6 ++-
xc_linux_build.c | 83 +
+-
3 files changed, 80 insertions(+), 54 deletions(-)
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
---
diff -r ed5ee9dde0bd tools/libxc/powerpc64/mk_flatdevtree.c
--- a/tools/libxc/powerpc64/mk_flatdevtree.c Sun Jan 21 08:17:46
2007 -0500
+++ b/tools/libxc/powerpc64/mk_flatdevtree.c Thu Jan 25 11:57:41
2007 -0600
@@ -316,13 +316,16 @@ int make_devtree(struct ft_cxt *root,
unsigned long shadow_mb,
unsigned long initrd_base,
unsigned long initrd_len,
- const char *bootargs)
+ const char *bootargs,
+ unsigned long console_evtchn,
+ unsigned long store_evtchn,
+ unsigned long nr_pages)
nr_pages no long needed
Since you later look for the console_mfn and store_mfn later, it
would be better in the caller and pass then in.
FYI: It is xend that decides where store and console go. shared_info
is a hypervisor contract so you can continue to calculate it here if
you want.
Also the devtree should not contain MFNs for frame numbers of any
kind, simply addresses.
{
struct boot_param_header *bph = NULL;
uint64_t val[2];
uint32_t val32[2];
unsigned long remaining;
-unsigned long rma_reserve = 4 * PAGE_SIZE;
+unsigned long rma_reserve = 3 * PAGE_SIZE;
base this on MIN(store, console)
unsigned long initrd_end = initrd_base + initrd_len;
int64_t shadow_mb_log;
uint64_t pft_size;
@@ -332,6 +335,9 @@ int make_devtree(struct ft_cxt *root,
char *cpuname = NULL;
int saved_errno;
int dtb_fd = -1;
+uint64_t shared_info_addr = (rma_bytes - PAGE_SIZE);
+uint64_t store_mfn = (rma_bytes - (2*PAGE_SIZE)) PAGE_SHIFT;
+uint64_t console_mfn = (rma_bytes - (3*PAGE_SIZE)) PAGE_SHIFT;
as above.. not MFNs
uint32_t cpu0_phandle = get_phandle();
uint32_t xen_phandle = get_phandle();
uint32_t rma_phandle = get_phandle();
@@ -419,11 +425,6 @@ int make_devtree(struct ft_cxt *root,
/* xen = root.addnode('xen') */
ft_begin_node(root, xen);
-/* start-info is the first page in the RMA reserved area */
-val[0] = cpu_to_be64((u64) (rma_bytes - rma_reserve));
-val[1] = cpu_to_be64((u64) PAGE_SIZE);
-ft_prop(root, start-info, val, sizeof(val));
-
/* xen.addprop('version', 'Xen-3.0-unstable\0') */
ft_prop_str(root, version, Xen-3.0-unstable);
This property should be called compatible
@@ -432,6 +433,11 @@ int make_devtree(struct ft_cxt *root,
val[1] = cpu_to_be64((u64) 0);
ft_prop(root, reg, val, sizeof(val));
+/* point to shared_info_t page base addr */
+val[0] = cpu_to_be64((u64) shared_info_addr);
+val[1] = cpu_to_be64((u64) PAGE_SIZE);
+ft_prop(root, shared-info, val, sizeof(val));
+
/* xen.addprop('domain-name', imghandler.vm.getName() + '\0') */
/* libxc doesn't know the domain name, that is purely a xend
thing */
/* ft_prop_str(root, domain-name, domain_name); */
@@ -442,12 +448,33 @@ int make_devtree(struct ft_cxt *root,
/* xencons = xen.addnode('console') */
ft_begin_node(root, console);
-/* xencons.addprop('interrupts', 1, 0) */
-val32[0] = cpu_to_be32((u32) 1);
+/* console_mfn */
+val[0] = cpu_to_be64((u64) console_mfn);
address
+val[1] = cpu_to_be64((u64) PAGE_SIZE);
+ft_prop(root, reg, val, sizeof(val));
+
+/* xencons.addprop('interrupts', console_evtchn, 0) */
+val32[0] = cpu_to_be32((u32) console_evtchn);
val32[1] = cpu_to_be32((u32) 0);
ft_prop(root, interrupts, val32, sizeof(val32));
/* end
Re: [XenPPC] [PATCH] xend: Don't ignore shadow memory requirement
pushed, thanks ryan -JX On Jan 25, 2007, at 2:32 PM, Ryan Harper wrote: We don't need a custom buildDomain() anymore but we do need to provide a shadow memory calculation. - Create PPC_LinuxImageHandler class to implement getRequiredShadowMemory(). - Derive prose builder from PPC_LinuxImageHandlerClass. - Drop configure() as it is not needed according to Jimi. Signed-off-by: Ryan Harper [EMAIL PROTECTED] ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 1/3] libxc: add start_info_t node to devtree
On Jan 25, 2007, at 3:51 PM, Ryan Harper wrote:
* Jimi Xenidis [EMAIL PROTECTED] [2007-01-25 14:40]:
Since you later look for the console_mfn and store_mfn later, it
would be better in the caller and pass then in.
FYI: It is xend that decides where store and console go.
shared_info
is a hypervisor contract so you can continue to calculate it
here if
you want.
Also the devtree should not contain MFNs for frame numbers of any
kind, simply addresses.
I don't follow. the start_info_t structure explicitly wants an
mfn, how
else am I suppose to fill that value out in linux?
they are MFNs on x86, in PPC they are domain physical addresses.
Maybe I've just got it named funny, I don't know. And I'm still
confused as to what you want me to put in?
I'm suggesting that we do not use a frame number in the devtree but
use the address that the frame number represents.
On PPC, MFN is a misnomer, this value is not an MFN but a domain PFN
(that is the page belongs to the domain), its just a bad name for us
because the structure is for x86. Later (on PPC) we convert the
domain PFN to and phys addr.
The value that I put in start_info-console.domU.mfn is:
((rma_pages 12) - (2*PAGE_SIZE)) PAGE_SHIFT
where rma_pages = (1 26) PAGE_SHIFT
the resulting value is 0x3ffe. Is this value correct and I just
have an
incorrect name for it (mfn)?
yes
Am I getting lucky? I've tested the
patches and dom0 and domU boot.
Not luck, we just preserved a crappy name for a crappy struct that in
PPC land will dissapear.
{
struct boot_param_header *bph = NULL;
uint64_t val[2];
uint32_t val32[2];
unsigned long remaining;
-unsigned long rma_reserve = 4 * PAGE_SIZE;
+unsigned long rma_reserve = 3 * PAGE_SIZE;
base this on MIN(store, console)
Why? Don't we always have a store and a console page?
yes we do, but they could be in any order, all you are trying to do
is make sure the pages are in the reserve map. Another possibility
is you could not assume contiguity and create a reservation entry for
each of the three pages.
I don't understand what is wrong with the above. We are reserving the
last X pages of the RMA. 1 for shared_info, 1 for console, one for
store. I futher don't understand what the value MIN(store,console)
gives me. Sorry for being dense here.
I know it is confusing, thats why it is so important we get it right.
First, I suggested that you pass in these addresses.
Once they are passed in, this function has no idea which one has the
lowest address.
There is nothing from stoping from changing the order of these 2
pages, as long as both sides agree.
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH 1/3] libxc: add start_info_t node to devtree
The data that was in start_info_t should be just simple bindings in /
xen since they describe xen, there is no need to create a new node.
many of the props are not needed since they are expressed elsewhere
in the devtree or perhaps differently.
more below.
On Jan 24, 2007, at 12:41 PM, Ryan Harper wrote:
This patch creates a new node, /xen/start_info_t in the flat devtree.
It adds a property for each field of the start_info_t structure that
xc_linux_build used to fill-out. I've also removed the helper
functions
which created/filled-out the start_info_t structure.
This patch depends on Patch2 which modifies linux:xen_init_early().
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
mk_flatdevtree.c | 36 +-
mk_flatdevtree.h |6 ++--
xc_linux_build.c | 76 ++
+
3 files changed, 67 insertions(+), 51 deletions(-)
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
---
diff -r ed5ee9dde0bd tools/libxc/powerpc64/mk_flatdevtree.c
--- a/tools/libxc/powerpc64/mk_flatdevtree.c Sun Jan 21 08:17:46
2007 -0500
+++ b/tools/libxc/powerpc64/mk_flatdevtree.c Tue Jan 23 09:50:43
2007 -0600
@@ -316,7 +316,10 @@ int make_devtree(struct ft_cxt *root,
unsigned long shadow_mb,
unsigned long initrd_base,
unsigned long initrd_len,
- const char *bootargs)
+ const char *bootargs,
+ unsigned long console_evtchn,
+ unsigned long store_evtchn,
+ unsigned long nr_pages)
{
struct boot_param_header *bph = NULL;
uint64_t val[2];
@@ -419,11 +422,6 @@ int make_devtree(struct ft_cxt *root,
/* xen = root.addnode('xen') */
ft_begin_node(root, xen);
-/* start-info is the first page in the RMA reserved area */
-val[0] = cpu_to_be64((u64) (rma_bytes - rma_reserve));
-val[1] = cpu_to_be64((u64) PAGE_SIZE);
-ft_prop(root, start-info, val, sizeof(val));
-
/* xen.addprop('version', 'Xen-3.0-unstable\0') */
ft_prop_str(root, version, Xen-3.0-unstable);
@@ -448,6 +446,32 @@ int make_devtree(struct ft_cxt *root,
ft_prop(root, interrupts, val32, sizeof(val32));
/* end of console */
+ft_end_node(root);
+
+/* mark up start_info fields here */
+ft_begin_node(root, start_info_t);
+
+ft_prop_str(root, magic, xen-3.0-powerpc64HV);
No need for magic since we are not trying to verify that the memory
location is good.
If we _do_ need this as some kind of compatibility statement then I'd
say the property name is compatible
+
+val[0] = cpu_to_be64((u64) nr_pages);
+ft_prop(root, nr_pages, (val[0]), sizeof(val[0]));
/memory node has this covered and linux knows about it, AFAICT we
don't need it at all
If we do need it then you'll have to walk the LMB and count the pages
like it is done in:
arch/powerpc/mm/hash_utils_64.c htab_initialize 429 void __init
htab_initialize(void )
+
+val[0] = cpu_to_be64((u64) (rma_bytes - PAGE_SIZE));
+ft_prop(root, shared_info, (val[0]), sizeof(val[0]));
memory areas generally contain a size so that should be included.
I believe that _ is reserved for the standard root bindings, use
use -.
So the name should be shared-info
+
+val[0] = cpu_to_be64((u64) ((rma_bytes PAGE_SHIFT) - 2));
+ft_prop(root, store_mfn, (val[0]), sizeof(val[0]));
To there are to items that describe Xen Store, its location and its
interrupt.
I would think the correct binding here is:
/xen/store/reg: store_mfn PAGE_SHIFT
/xen/store/interrupts: store_evtchn 0
the latter is 2 ints.
Same goes for console.
+
+ft_prop_int(root, store_evtchn, store_evtchn);
+
+/* start_info-console.domU.mfn */
+val[0] = cpu_to_be64((u64) ((rma_bytes PAGE_SHIFT) - 3));
+ft_prop(root, console_domU_mfn, (val[0]), sizeof(val[0]));
+
+/* start_info-console.domU.evtchn */
+ft_prop_int(root, console_domU_evtchn, console_evtchn);
+
+/* end of start_info_t */
ft_end_node(root);
/* end of xen node */
diff -r ed5ee9dde0bd tools/libxc/powerpc64/mk_flatdevtree.h
--- a/tools/libxc/powerpc64/mk_flatdevtree.h Sun Jan 21 08:17:46
2007 -0500
+++ b/tools/libxc/powerpc64/mk_flatdevtree.h Mon Jan 22 15:38:46
2007 -0600
@@ -32,8 +32,10 @@ extern int make_devtree(struct ft_cxt *r
unsigned long shadow_mb,
unsigned long initrd_base,
unsigned long initrd_len,
-const char *bootargs);
-
+const char *bootargs,
+unsigned long console_evtchn,
+unsigned long store_evtchn,
+unsigned long nr_pages);
#define MAX_PATH 200
#define BUFSIZE 1024
#define BPH_SIZE 16*1024
diff -r ed5ee9dde0bd tools/libxc/powerpc64/xc_linux_build.c
---
[XenPPC] Build/config the world!
In case you missed it, a lot has been going on so please: 1. reconfigure and build your linux 2. rebuild your Xen management tools (make install-tools) 3. and don't forget to rebuild xen :) -JX ___ 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 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. 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? More importantly... (and this needs to be addressed before the patch is accepted) I like the map name change, but not sure about early. oops this last line slipped by.. I wrote the email over multiple sittings. What is your request? Just renaming it? My point is the early is not the only reason mini was used. There are 2 reasons why we had mini/inline/early: 1) because the allocator was not ready, I think this applies to a small number of hcalls 2) we cannot sleep (in_interrupt()) and the allocator sleeps, Mainly evtchn related and console. So early covers (1) but (2) will be problematic, I noted the ones below that may reflect (2), I for one, have not been diligent in commenting why mini/inline is actually used and I think we need to do so. What, add a comment describing a code path that may change in the future? I would object to that. Was that sarcasm? So giving this some more thought, and jerking you around even more (sorry), aside from using inline to optimize this: - We can detect (1) with slab_is_available() and use mini - We can detect (2) with in_interrupt() and try GFP_ATOMIC then mini. Not a request, but something to think about. What *is* your request then, the one that needs to be addressed? My request is that ,at a minimum, everything that was inline/mini must be _early because we cannot alloc anything while in_interrupt(). Ultimately, we call the right allocator at the right time. And since we have interfaces to detect both early and in_interrupt we can probably bring this down to a single inteligent xencomm_map() call. Mini, has always bugged me, it seems to me that this could be satisfied by a per_cpu static, or preallocated buffer to for the xen descriptor. This may not be viable because it assumes no interrupts, and though for asynchronous interrupts this may be a safe assumption, if one were to suffer a series of page faults (from a wild pointer in this path) we would have a silent hang, which is never good. So mini has always bugged you, but you agree there's no better way to do it and are just thinking out loud? yes. -JX ___ 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 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);
}
}
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH 3/3] [XEN] Handle the uint32_t in the tbuf
Signed-off-by: Jimi Xenidis [EMAIL PROTECTED]
---
diff -r 58d6c9cb95c6 tools/libxc/xc_tbuf.c
--- a/tools/libxc/xc_tbuf.c Wed Jan 17 14:57:04 2007 -0500
+++ b/tools/libxc/xc_tbuf.c Wed Jan 17 17:13:10 2007 -0500
@@ -96,15 +96,25 @@ int xc_tbuf_set_cpu_mask(int xc_handle,
{
DECLARE_SYSCTL;
int ret = -1;
+uint64_t mask64;
+uint8_t local[sizeof (mask64)];
sysctl.cmd = XEN_SYSCTL_tbuf_op;
sysctl.interface_version = XEN_SYSCTL_INTERFACE_VERSION;
sysctl.u.tbuf_op.cmd = XEN_SYSCTL_TBUFOP_set_cpu_mask;
-set_xen_guest_handle(sysctl.u.tbuf_op.cpu_mask.bitmap, (uint8_t *)mask);
-sysctl.u.tbuf_op.cpu_mask.nr_cpus = sizeof(mask) * 8;
+#ifdef XC_BIG_ENDIAN
+mask64 = mask;
+#else
+mask64 = (uint64_t)mask 32;
+#endif
-if ( lock_pages(mask, sizeof(mask)) != 0 )
+bitmap_64_to_byte(local, mask64, sizeof (mask64));
+
+set_xen_guest_handle(sysctl.u.tbuf_op.cpu_mask.bitmap, local);
+sysctl.u.tbuf_op.cpu_mask.nr_cpus = sizeof(local) * 8;
+
+if ( lock_pages(local, sizeof(local)) != 0 )
{
PERROR(Could not lock memory for Xen hypercall);
goto out;
@@ -112,7 +122,7 @@ int xc_tbuf_set_cpu_mask(int xc_handle,
ret = do_sysctl(xc_handle, sysctl);
-unlock_pages(mask, sizeof(mask));
+unlock_pages(local, sizeof(local));
out:
return ret;
___
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 Jan 16, 2007, at 10:05 AM, Ryan Harper wrote: * Hollis Blanchard [EMAIL PROTECTED] [2007-01-15 20:44]: 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. Even though we aren't making the tree in python we are still loading it at DEVTREE_ADDR no? Why don't we need it? First off, the length is bogus. The reservation list is to let the OS know immediately what memory the devtree and all it references are occupying. However the devtree's header contains the real devtree size and the domain is given its location. So the reservation entry is really redundant and makes relocating the devtree to an arbitrary location in memory more difficult. ___ 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()
Scratch this! I do not think this entry is for the devtree, I think
it is the bogus entry that we create to optionally reserve the memory
for the initrd, this was a side effect of creating the devtree in the
python tree.
So now that its in libxc we can clean it up. We must have made it
redundant because we did not want to leave it as zero, since that
terminates the reservation list.
Here is the patch so far.
+/* XXX:NB: you MUST set reservations BEFORE
_starting_the_tree_ */
+
This is the redundant entry that allows us to fill in the optional
initrd memory.
We make it first to make it easy to find later, but this should no
longer be necessary.
+/* 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]);
+
This is the entry that reserves the last 4 pages of the RMA, so
obviously this need to be hang off of rma_bytes as well.
+/* root.reserve(0x3ffc000, 0x4000 */
+val[0] = cpu_to_be64((u64) 0x3ffc000);
+val[1] = cpu_to_be64((u64) 0x4000);
+ft_add_rsvmap(root, val[0], val[1]);
+
And then there is the implicit terminating entry that is all zeros.
I also notice that:
+/* xc_linux_load.c will overwrite these 64-bit properties later
+*
+* chosen.addprop('linux,initrd-start', long(0))
+* chosen.addprop('linux,initrd-end', long(0)))
+*/
+val[0] = cpu_to_be64((u64) 0);
+ft_prop(root, linux,initrd-start, val, sizeof(val[0]));
+ft_prop(root, linux,initrd-end, val, sizeof(val[0]));
Now that we do this in libcx, we _can_ know the answer and define
them once and even drop the prop and reservation if there _is_ no
initrd.
-JX
On Jan 16, 2007, at 10:13 AM, Jimi Xenidis wrote:
On Jan 16, 2007, at 10:05 AM, Ryan Harper wrote:
* Hollis Blanchard [EMAIL PROTECTED] [2007-01-15 20:44]:
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.
Even though we aren't making the tree in python we are still
loading it
at DEVTREE_ADDR no? Why don't we need it?
First off, the length is bogus.
The reservation list is to let the OS know immediately what memory
the devtree and all it references are occupying. However the
devtree's header contains the real devtree size and the domain is
given its location. So the reservation entry is really redundant
and makes relocating the devtree to an arbitrary location in memory
more difficult.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] console in the background
On Sep 10, 2006, at 2:57 AM, Muli Ben-Yehuda wrote: On Sat, Sep 09, 2006 at 08:04:38PM -0400, Maria Butrico wrote: Putting the partition xen console in the background (e. g, xm create -c ... or xm console ) seems to kill the console (xenconsole) process. Is this behavior expected? Certainly not the expected use :) Is this with my xenconsole patch or without it? assuming without it, xenconsole always writes to stdout and reads from stdin, so I would expect it to be stopped as soon as you background it. This is what I would expect as well. are you sure its just not stopped? -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Cannot boot from local disk
splitting continues On Oct 6, 2006, at 7:59 AM, Jimi Xenidis wrote: Kawachiya-san, thank you for the exhaustive analysis! On Oct 6, 2006, at 7:38 AM, Kiyokuni Kawachiya wrote: 3. I also cannot boot the official XenPPC in XenSource, which I already reported. : Welcome to yaboot version 10.1.14-r716.SuSE booted from '/ht/[EMAIL PROTECTED],1/[EMAIL PROTECTED]' Enter help to get some basic usage information boot: xen Please wait, loading kernel... Can't find a loadable segment ! boot: I think this is related to the boot wrapper removal. It probably is, which image do you copy for yaboot to use? can you try: $ objcopy -S xen/xen-syms xen/xen.yaboot and have yaboot load xen.yaboot I seem to recall yaboot having difficulties with 32bit images, I'm surprised that the change sa made any difference. Can you tell us if the striping worked? -JX ___ 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 Jan 15, 2007, at 1:51 PM, Ryan Harper wrote:
* Jimi Xenidis [EMAIL PROTECTED] [2007-01-11 16:53]:
Ok there are a few things here.
BTW: some of these issues existed in the original python, but they
are yours now :)
Respun with fixes:
- preserve and return errno where approriate
- using open/close and read/write instead of f*
- dropped vcpu argument, only fill out one cpu in devtree
- dropped regexp requirment, use a null-terminated list of filters
- made sure to call closedir()
- fixed double-free of bph on error path
- fixed static function names
- renamed find_first_cpu to find_cpu, we don't care which cpu we find
I believe you _must_ use the the entry that has a reg property of 0.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
diffstat output:
b/tools/libxc/powerpc64/mk_flatdevtree.c | 567 +++
b/tools/libxc/powerpc64/mk_flatdevtree.h | 44 ++
tools/libxc/powerpc64/Makefile |1
tools/libxc/powerpc64/xc_linux_build.c | 30 +
tools/libxc/xenguest.h |4
tools/python/xen/lowlevel/xc/xc.c| 12
tools/python/xen/xend/image.py |5
7 files changed, 646 insertions(+), 17 deletions(-)
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
---
[PATCH] Move flat device tree construction from python to libxc for
xc_linux_build().
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
diff -r 3edbfb956864 tools/libxc/powerpc64/Makefile
--- a/tools/libxc/powerpc64/MakefileFri Jan 12 15:16:42 2007 -0600
+++ b/tools/libxc/powerpc64/MakefileFri Jan 12 15:16:42 2007 -0600
@@ -1,4 +1,5 @@ GUEST_SRCS-y += powerpc64/flatdevtree.c
GUEST_SRCS-y += powerpc64/flatdevtree.c
+GUEST_SRCS-y += powerpc64/mk_flatdevtree.c
GUEST_SRCS-y += powerpc64/xc_linux_build.c
GUEST_SRCS-y += powerpc64/xc_prose_build.c
GUEST_SRCS-y += powerpc64/utils.c
diff -r 3edbfb956864 tools/libxc/powerpc64/xc_linux_build.c
--- a/tools/libxc/powerpc64/xc_linux_build.c Fri Jan 12 15:16:42
2007 -0600
+++ b/tools/libxc/powerpc64/xc_linux_build.c Fri Jan 12 16:00:33
2007 -0600
@@ -13,9 +13,10 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.
*
- * Copyright (C) IBM Corporation 2006
+ * Copyright IBM Corporation 2006, 2007
*
* Authors: Hollis Blanchard [EMAIL PROTECTED]
+ * Ryan Harper [EMAIL PROTECTED]
*/
#include stdio.h
@@ -36,6 +37,7 @@
#include flatdevtree_env.h
#include flatdevtree.h
#include utils.h
+#include mk_flatdevtree.h
#define INITRD_ADDR (24UL 20)
#define DEVTREE_ADDR (16UL 20)
@@ -238,8 +240,7 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn,
- void *devtree)
+ unsigned long *console_mfn)
{
start_info_t start_info;
struct domain_setup_info dsi;
@@ -251,12 +252,34 @@ int xc_linux_build(int xc_handle,
unsigned long initrd_len = 0;
unsigned long start_info_addr;
unsigned long rma_pages;
+unsigned long shadow_mb;
int rc = 0;
+int op;
+struct ft_cxt root;
+void *devtree;
DPRINTF(%s\n, __func__);
nr_pages = mem_mb (20 - PAGE_SHIFT);
DPRINTF(nr_pages 0x%lx\n, nr_pages);
+
+/* fetch the current shadow_memory value for this domain */
+op = XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION;
+if (xc_shadow_control(xc_handle, domid, op, NULL, 0,
shadow_mb, 0, NULL) 0 ) {
+rc = -1;
+goto out;
+}
+
+/* build the devtree here */
+DPRINTF(constructing devtree\n);
+if (make_devtree(root, domid, mem_mb, shadow_mb, cmdline) 0) {
+DPRINTF(failed to create flattened device tree\n);
+rc = -1;
+goto out;
+}
+
+/* point devtree at bph blob */
+devtree = root.bph;
rma_pages = get_rma_pages(devtree);
if (rma_pages == 0) {
@@ -314,6 +337,7 @@ int xc_linux_build(int xc_handle,
}
out:
+free_devtree(root);
free_page_array(page_array);
return rc;
}
diff -r 3edbfb956864 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.hFri Jan 12 15:16:42 2007 -0600
+++ b/tools/libxc/xenguest.hFri Jan 12 17:08:40 2007 -0600
@@ -57,7 +57,6 @@ int xc_linux_restore(int xc_handle, int
* @parm store_mfn returned with the mfn of the store page
* @parm console_evtchn the console event channel for this domain
to use
* @parm console_mfn returned with the mfn of the console page
- * @parm arch_args architecture-specific data
* @return 0 on success, -1 on failure
*/
int xc_linux_build(int xc_handle,
@@ -71,8 +70,7 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int
Re: [XenPPC] [PATCH 3 of 4] [PATCH] Move flat device tree construction from python to libxc for xc_linux_build()
On Jan 15, 2007, at 4:13 PM, Ryan Harper wrote:
* Jimi Xenidis [EMAIL PROTECTED] [2007-01-15 14:53]:
On Jan 15, 2007, at 1:51 PM, Ryan Harper wrote:
* Jimi Xenidis [EMAIL PROTECTED] [2007-01-11 16:53]:
[snip]
- renamed find_first_cpu to find_cpu, we don't care which cpu we
find
I believe you _must_ use the the entry that has a reg property of 0.
Is that because the properties we are interested aren't guaranteed
to be
present in all cpu nodes?
Well I would like it to have a reg=0 and cpu#=0
Some OF devtrees contain nodes that described shares resources (like
L3, L4 caches), usually the full definition is in the lowest number
of the sharers and the secondaries can simply us a property that
contains the phandle of the original node.
[snip]
SEGVs are good! :)
WFM. =)
No.. seriously!
[snip]
+static int copynode(struct ft_cxt *cxt, const char *dirpath, const
char **propfilter)
+{
This is totally informational, but I think the blob/fnmatch routines
may make this code way simpler.
sure and I liked my regexp, but the concern was what sort of libc
functions would be available in Xen when we implement copynode down
there for dom0 devtree construction.
this is a good point, however dom0 will copy everything.
[snip]
+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]);
Hollis?!
+
this value is keyed off of rma_bytes
No idea, just duping reservations that the python code made. Is there
some place I should be getting these values from?
Sure.. you calculate rma_bytes below when you fill in the /[EMAIL PROTECTED]
stuff in.
that is what you are missing below.
[snip]
+/* xen = root.addnode('xen') */
+ft_begin_node(root, xen);
the 0x3ffc00 value is offset from rma_bytes
+
+/* xen.addprop('start-info', long(0x3ffc000), long(0x1000)) */
+val[0] = cpu_to_be64((u64) 0x3ffc000);
+val[1] = cpu_to_be64((u64) 0x1000);
+ft_prop(root, start-info, val, sizeof(val));
What am I missing here?
+
+/* [EMAIL PROTECTED] is all the rest */
+if (remaining 0)
+{
this really should be memory@rma_bytes
+/* mem = root.addnode('[EMAIL PROTECTED]') */
+ft_begin_node(root, [EMAIL PROTECTED]);
+
OK.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253 T/L: 678-9253
[EMAIL PROTECTED]
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] [POWERPC][XEN] Mark heap memory based on boot_of.c's allocator
Please double-check the usedbit issue below otherwise I'll ACK this.
-JX
On Jan 11, 2007, at 4:51 PM, Hollis Blanchard wrote:
# HG changeset patch
# User Hollis Blanchard [EMAIL PROTECTED]
# Date 1168550320 21600
# Node ID d98b2fbc100cfec5678a787ba7bfd0b065254793
# 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 d98b2fbc100c 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.cThu Jan 11 15:18:40 2007 -0600
@@ -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,33 @@ static ulong boot_of_alloc(ulong size)
pos = pos + i;
}
+}
+
+int boot_of_mem_avail(int pos, ulong *startpage, ulong *endpage)
If you'd like to hide the bitmap, then perhaps the first arg should
be a start address and return the address of the next used page?
+{
+ulong freebit;
+ulong usedbit;
+
+/* 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 -1;
+}
+*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 -1;
+}
+*endpage = usedbit PAGE_SHIFT;
I'm not 100% but the code below looks like require that end represent
a free page so usedbit - 1?
+
+return usedbit;
}
static ulong boot_of_mem_init(void)
diff -r dbc74db14a4b -r d98b2fbc100c 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 Thu Jan 11 15:18:40 2007 -0600
@@ -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);
total_pages += (end_blk - start_blk) PAGE_SHIFT;
}
@@ -141,72 +116,31 @@ 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
-
Re: [XenPPC] [PATCH 3 of 4] [PATCH] Move flat device tree construction from python to libxc for xc_linux_build()
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? -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] IPI problems
Please check if you linux kernel is up to date.
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
I created an NFS domain and Did get:
(XEN) Assertion '!cpu_isset(nxt, cpu_core_map[cpu])' failed, line
465, file schc
(XEN) BUG at sched_credit.c:465
(XEN) [ Xen-3.0-unstable ]
(XEN) CPU: 0001 DOMID: 0001
(XEN) pc c003c3d0 msr 80009032
(XEN) lr c0045f54 ctr c0045f40
(XEN) srr0 srr1
(XEN) r00: 2488 c0673cc0 c066df00
(XEN) r04: 0001 2482
c00100a8
(XEN) r08: c0670080 c0045f40 c067
c0045e78
(XEN) r12: c11ceb90 c0546100
(XEN) r16:
(XEN) r20:
(XEN) r24: 4000
c000
(XEN) r28: c06c4fc8 c05552e8
0001
(XEN)
(XEN)
(XEN) Panic on CPU 1:
(XEN) BUG at sched_credit.c:465
(XEN)
(XEN)
(XEN) Reboot in five seconds...
(XEN) [ Xen-3.0-unstable ]
(XEN) CPU: 0001 DOMID: 0001
(XEN) pc c003c3d0 msr 80009032
(XEN) lr c0045f54 ctr c0045f40
(XEN) srr0 srr1
(XEN) r00: 2488 c0673cc0 c066df00
(XEN) r04: 0001 2482
c00100a8
(XEN) r08: c0670080 c0045f40 c067
c0045e78
(XEN) r12: c11ceb90 c0546100
(XEN) r16:
(XEN) r20:
(XEN) r24: 4000
c000
(XEN) r28: c06c4fc8 c05552e8
0001
(XEN) [0033B6F0] 00435364 .debugger_trap_immediate
+0x18/0x38
(XEN) [0033B770] 004352C8 .panic+0xe8/0x16c
(XEN) [0033B890] 0043544C .__bug+0x5c/0x6c
(XEN) [0033B910] 0041E3A0 .csched_cpu_pick+0x328/0x458
(XEN) [0033B9E0] 0041ED70 .csched_vcpu_acct+0x144/0x1dc
(XEN) [0033BA70] 00421170 .csched_tick+0x48/0xe8
(XEN) [0033BB10] 00429DD8 .t_timer_fn+0xec/0x164
(XEN) [0033BBC0] 0042DBA4 .timer_softirq_action
+0xd0/0x1b8
(XEN) [0033BC90] 0042A758 .do_softirq+0xc4/0xec
(XEN) [0033BD20] 00455AC4 test_all_events+0x5c/0x64
(XEN) [0043EDE0] 80010001FBE1FFF8
(XEN) SP (60004bd8) is not in xen space
On Jan 12, 2007, at 6:45 PM, Hollis Blanchard wrote:
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)
+{
+
Re: [XenPPC] [PATCH 4 of 4] [PATCH] Remove FlatDeviceTree.py, move prose builder to libxc devtree construction
Straight off, prose should have no flat tree reference at all.
-JX
On Jan 11, 2007, at 1:42 PM, Ryan Harper wrote:
5 files changed, 48 insertions(+), 376 deletions(-)
tools/python/xen/xend/FlatDeviceTree.py | 359
---
tools/libxc/powerpc64/xc_prose_build.c | 44 +++
tools/libxc/xenguest.h |3
tools/python/xen/lowlevel/xc/xc.c | 12 -
tools/python/xen/xend/image.py |6
# HG changeset patch
# User Ryan Harper [EMAIL PROTECTED]
# Date 1168544367 21600
# Node ID a2ff54d361f5853ff83adedfe0d7bbc63363bfdc
# Parent e4fda6c5e7a907b5e4726c4f4d5f117c0f4d6f50
[PATCH] Remove FlatDeviceTree.py, move prose builder to libxc
devtree construction.
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
diff -r e4fda6c5e7a9 -r a2ff54d361f5 tools/libxc/powerpc64/
xc_prose_build.c
--- a/tools/libxc/powerpc64/xc_prose_build.c Thu Jan 11 13:39:27
2007 -0600
+++ b/tools/libxc/powerpc64/xc_prose_build.c Thu Jan 11 13:39:27
2007 -0600
@@ -13,10 +13,11 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.
*
- * Copyright (C) IBM Corporation 2006
+ * Copyright IBM Corporation 2006
*
* Authors: Hollis Blanchard [EMAIL PROTECTED]
* Jonathan Appavoo [EMAIL PROTECTED]
+ * Ryan Harper [EMAIL PROTECTED]
*/
#include stdio.h
@@ -37,6 +38,7 @@
#include flatdevtree_env.h
#include flatdevtree.h
#include utils.h
+#include mk_flatdevtree.h
#define INITRD_ADDR (24UL 20)
#define DEVTREE_ADDR (16UL 20)
@@ -239,8 +241,7 @@ int xc_prose_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn,
- void *devtree)
+ unsigned long *console_mfn)
{
start_info_t start_info;
struct domain_setup_info dsi;
@@ -252,7 +253,13 @@ int xc_prose_build(int xc_handle,
unsigned long initrd_len = 0;
unsigned long start_info_addr;
unsigned long rma_pages;
+unsigned long shadow_mb;
int rc = 0;
+int op;
+uint32_t nr_vcpus;
+xc_dominfo_t info;
+struct ft_cxt root;
+void *devtree;
DPRINTF(%s\n, __func__);
@@ -260,6 +267,36 @@ int xc_prose_build(int xc_handle,
nr_pages = mem_mb (20 - PAGE_SHIFT);
DPRINTF(nr_pages 0x%lx\n, nr_pages);
+
+/* XXX: fetch the number of vcpus configured for this domain
+ checking that xc_domain_getinfo returns info for exactly 1
+ dom */
+if (xc_domain_getinfo(xc_handle, domid, 1, info) != 1) {
+DPRINTF(xc_domain_getinfo() failed, can't determine
max_vcpu_id\n);
+rc = -1;
+goto out;
+}
+
+/* NB: max_vcpu_id is zero-based */
+nr_vcpus = info.max_vcpu_id + 1;
+
+/* XXX: fetch the current shadow_memory value for this domain */
+op = XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION;
+if (xc_shadow_control(xc_handle, domid, op, NULL, 0,
shadow_mb, 0, NULL) 0 ) {
+rc = -1;
+goto out;
+}
+
+/* build the devtree here */
+DPRINTF(constructing devtree\n);
+if (make_devtree(root, domid, mem_mb, nr_vcpus, shadow_mb,
cmdline) 0) {
+DPRINTF(failed to create flattened device tree\n);
+rc = -1;
+goto out;
+}
+
+/* point devtree at bph blob */
+devtree = root.bph;
rma_pages = get_rma_pages(devtree);
if (rma_pages == 0) {
@@ -318,6 +355,7 @@ int xc_prose_build(int xc_handle,
}
out:
+free_devtree(root.bph);
free_page_array(page_array);
return rc;
}
diff -r e4fda6c5e7a9 -r a2ff54d361f5 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.hThu Jan 11 13:39:27 2007 -0600
+++ b/tools/libxc/xenguest.hThu Jan 11 13:39:27 2007 -0600
@@ -138,7 +138,6 @@ int xc_prose_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn,
- void *arch_args);
+ unsigned long *console_mfn);
#endif /* XENGUEST_H */
diff -r e4fda6c5e7a9 -r a2ff54d361f5 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c Thu Jan 11 13:39:27 2007 -0600
+++ b/tools/python/xen/lowlevel/xc/xc.c Thu Jan 11 13:39:27 2007 -0600
@@ -378,28 +378,26 @@ static PyObject *pyxc_prose_build(XcObje
unsigned int mem_mb;
unsigned long store_mfn = 0;
unsigned long console_mfn = 0;
-void *arch_args = NULL;
int unused;
static char *kwd_list[] = { dom, store_evtchn, memsize,
console_evtchn, image,
/* optional */
ramdisk, cmdline, flags,
-features, arch_args, NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, s|ssiss#,
Re: [XenPPC] [PATCH 3 of 4] [PATCH] Move flat device tree construction from python to libxc for xc_linux_build()
Ok there are a few things here.
On Jan 11, 2007, at 1:42 PM, Ryan Harper wrote:
7 files changed, 617 insertions(+), 17 deletions(-)
tools/libxc/powerpc64/Makefile |1
tools/libxc/powerpc64/mk_flatdevtree.c | 520 ++
++
tools/libxc/powerpc64/mk_flatdevtree.h | 48 ++
tools/libxc/powerpc64/xc_linux_build.c | 44 ++
tools/libxc/xenguest.h |4
tools/python/xen/lowlevel/xc/xc.c | 12
tools/python/xen/xend/image.py |5
# HG changeset patch
# User Ryan Harper [EMAIL PROTECTED]
# Date 1168544367 21600
# Node ID e4fda6c5e7a907b5e4726c4f4d5f117c0f4d6f50
# Parent 0279229b68453a4a1b3613ac02c8b8ca9a965875
[PATCH] Move flat device tree construction from python to libxc for
xc_linux_build().
Signed-off-by: Ryan Harper [EMAIL PROTECTED]
diff -r 0279229b6845 -r e4fda6c5e7a9 tools/libxc/powerpc64/Makefile
--- a/tools/libxc/powerpc64/MakefileThu Jan 11 13:39:27 2007 -0600
+++ b/tools/libxc/powerpc64/MakefileThu Jan 11 13:39:27 2007 -0600
@@ -1,4 +1,5 @@ GUEST_SRCS-y += powerpc64/flatdevtree.c
GUEST_SRCS-y += powerpc64/flatdevtree.c
+GUEST_SRCS-y += powerpc64/mk_flatdevtree.c
GUEST_SRCS-y += powerpc64/xc_linux_build.c
GUEST_SRCS-y += powerpc64/xc_prose_build.c
GUEST_SRCS-y += powerpc64/utils.c
diff -r 0279229b6845 -r e4fda6c5e7a9 tools/libxc/powerpc64/
xc_linux_build.c
--- a/tools/libxc/powerpc64/xc_linux_build.c Thu Jan 11 13:39:27
2007 -0600
+++ b/tools/libxc/powerpc64/xc_linux_build.c Thu Jan 11 13:39:27
2007 -0600
@@ -13,9 +13,10 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
02111-1307, USA.
*
- * Copyright (C) IBM Corporation 2006
+ * Copyright IBM Corporation 2006
*
* Authors: Hollis Blanchard [EMAIL PROTECTED]
+ * Ryan Harper [EMAIL PROTECTED]
*/
#include stdio.h
@@ -36,6 +37,7 @@
#include flatdevtree_env.h
#include flatdevtree.h
#include utils.h
+#include mk_flatdevtree.h
#define INITRD_ADDR (24UL 20)
#define DEVTREE_ADDR (16UL 20)
@@ -238,8 +240,7 @@ int xc_linux_build(int xc_handle,
unsigned int store_evtchn,
unsigned long *store_mfn,
unsigned int console_evtchn,
- unsigned long *console_mfn,
- void *devtree)
+ unsigned long *console_mfn)
{
start_info_t start_info;
struct domain_setup_info dsi;
@@ -251,12 +252,48 @@ int xc_linux_build(int xc_handle,
unsigned long initrd_len = 0;
unsigned long start_info_addr;
unsigned long rma_pages;
+unsigned long shadow_mb;
int rc = 0;
+int op;
+uint32_t nr_vcpus;
+xc_dominfo_t info;
+struct ft_cxt root;
+void *devtree;
DPRINTF(%s\n, __func__);
nr_pages = mem_mb (20 - PAGE_SHIFT);
DPRINTF(nr_pages 0x%lx\n, nr_pages);
+
+/* XXX: fetch the number of vcpus configured for this domain
+ checking that xc_domain_getinfo returns info for exactly 1
+ dom */
Hmm, you are doing this, what is the XXX for?
+if (xc_domain_getinfo(xc_handle, domid, 1, info) != 1) {
+DPRINTF(xc_domain_getinfo() failed, can't determine
max_vcpu_id\n);
+rc = -1;
+goto out;
+}
+
+/* NB: max_vcpu_id is zero-based */
+nr_vcpus = info.max_vcpu_id + 1;
Not sure what you are actually doing here, we boot all domains UP and
hotplug the rest, so the devtree will never have more than one CPU node.
+
+/* XXX: fetch the current shadow_memory value for this domain */
Again, why the XXX? are you Vin Diesel or Ice Cube?!
+op = XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION;
+if (xc_shadow_control(xc_handle, domid, op, NULL, 0,
shadow_mb, 0, NULL) 0 ) {
+rc = -1;
+goto out;
+}
+
+/* build the devtree here */
+DPRINTF(constructing devtree\n);
+if (make_devtree(root, domid, mem_mb, nr_vcpus, shadow_mb,
cmdline) 0) {
I'd expect make_devtree() to only take one argument and use separate
ft_* calls to fill in the rest of these params.
+DPRINTF(failed to create flattened device tree\n);
+rc = -1;
+goto out;
+}
+
+/* point devtree at bph blob */
+devtree = root.bph;
rma_pages = get_rma_pages(devtree);
if (rma_pages == 0) {
@@ -314,6 +351,7 @@ int xc_linux_build(int xc_handle,
}
out:
+free_devtree(root.bph);
free_page_array(page_array);
return rc;
}
diff -r 0279229b6845 -r e4fda6c5e7a9 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.hThu Jan 11 13:39:27 2007 -0600
+++ b/tools/libxc/xenguest.hThu Jan 11 13:39:27 2007 -0600
@@ -57,7 +57,6 @@ int xc_linux_restore(int xc_handle, int
* @parm store_mfn returned with the mfn of the store page
* @parm console_evtchn the console event channel for this domain
to use
* @parm console_mfn returned with the mfn of the console page
- * @parm arch_args architecture-specific data
* @return 0 on
Re: [XenPPC] [PATCH] Move lots of memory logic earlier
On Jan 10, 2007, at 12:43 PM, Hollis Blanchard wrote: On Tue, 2007-01-09 at 12:24 -0500, Jimi Xenidis wrote: 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. More precisely, it is OF-specific and exists because we cannot trust the claim OF-method, so really it is more of a workaround. You say we can't trust claim, hmm, trust implies a lot, I guess... but a) we trust available properties, We trust available to have correct information but not to be complete, or up to date. and b) we trust the return code from claim. Excellent point, we trust the claim is implemented and that it _may_ object if the address conflicts. If claim is not implemented _at_all_ then the current code would interpret it as rejecting all addresses and we would be screwed. So the only thing you could mean is that we don't trust that claims will be reflected in the available properties. Is that what you mean? Where have we seen that? IIRC: PIBS: - does not implement available, but may in the next release (so I'm told) - claim will tell you only about PIBS conflicts - will not tell you about conflicts with other claims or loaded images SLOF: - does implement, but does not update available, though recent resions might - claim will only tell you about conflicts its self - will not tell you about conflicts with other claims or loaded images GFW: does everything as spec'ed Apple: does everything as spec'ed -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: OF claim untrustworthy?
On Jan 10, 2007, at 4:29 PM, Hollis Blanchard wrote: 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. It does, the throw method would return an OF failure, this is expected. Can you test if you can use this to actually find an allocation by specifying addr=0 and align!=0? -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [patch] multiboot2 support
On Jan 9, 2007, at 12:09 PM, Hollis Blanchard wrote: On Thu, 2007-01-04 at 15:56 -0500, Jimi Xenidis wrote: We did a lot of work here so that stuff could be placed anywhere. I admit it was not pretty but I'd expect this patch to replace/improve not remove. The memmove below means this logic is unnecessary. I'd prefer some logic over blind moves of several megabytes (3-16), this will kill simulators. Wait a minute, doesn't systemsim has a passthrough call for memmove? If we should wire that up then this won't impact performance at all. We were/are trying to eliminate all simulator specific passthrus in the Xen core code. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [patch] multiboot2 support
On Jan 9, 2007, at 12:34 PM, Segher Boessenkool wrote: Wait a minute, doesn't systemsim has a passthrough call for memmove? If we should wire that up then this won't impact performance at all. We were/are trying to eliminate all simulator specific passthrus in the Xen core code. That sounds rather counterproductive. What's wrong with having some minimal passthroughs? They help performance a *lot*, it's quite painful to run without. Of course, a command line option to disable it would be nice. There are currently only 3 large copies in xen, dom0-kernel, dom0- initrd (optional), and dom0-devtree after that the passthru gains us very little since the passthru is unavailable to the domain since the passthru requires machine addresses. Thing is in fast mode systemsim is good enuff, right now the biggest simulation problem is uncompressing kernels, and even that is not so bad. We have only one required on_sim() call and that is because systemsim does not provide a DART simulation (which means that any IO is unusable). Further more, I'm hoping to see more simulators each having more accelerators further complicating the passthru logic. I'd rather simply push back to the simulators. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Timeline for migrating to newer Linux kernels?
On Mon, Jan 01, 2007 at 04:44:30PM +, Keir Fraser wrote: On 1/1/07 12:21 am, Rik van Riel [EMAIL PROTECTED] wrote: XenSource has usually been less than useful when it comes to tracking the upstream kernel. I suspect they'll be obsoleted by KVM and/or lhype at some point in the future, because those will just be there in the upstream kernel while Xen won't. If XenSource has any intention of having Xen stay relevant in the future, they'll want to seriously pursue an upstream merge of their code. There are ongoing efforts from (at least) XenSource, Novell, Red Hat and IBM to merge Xen support into upstream Linux. The paravirt_ops infrastructure is already merged for 2.6.20 and we will hopefully see implementations of the new interface, including Xen, merged for 2.6.21. As for the Linux sparse tree in xen-unstable, it will be upgraded and moved to a separate repository before 3.0.5. With the guest kernel interfaces having been stable for some time, it makes lots of sense to separate hypervisor development and its release cycle from that of guest kernels. Sorry for the disconnected reply, but is there a time line for this? how can other help? The xen-ppc team is lagging behind both kernel.org and sen-unstable and we've lost all hope of regaining a common root. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] fix debug print in boot_of_alloc_init
On Jan 8, 2007, at 5:46 PM, Yoder Stuart-B08248 wrote:
This is a minor bug in a debug print that most likely will never
be seen, as start is typically 0, but it is something I noticed.
thanks, but this patch is incorrect, see below
Signed-off-by: Stuart Yoder [EMAIL PROTECTED]
diff -r db52c7d043bb xen/arch/powerpc/boot_of.c
--- a/xen/arch/powerpc/boot_of.cTue Dec 19 09:20:58 2006 -0500
+++ b/xen/arch/powerpc/boot_of.cMon Jan 08 16:43:09 2007 -0600
@@ -419,7 +419,7 @@ static void boot_of_alloc_init(int m, ui
start = ALIGN_UP(start, PAGE_SIZE);
start is in bytes here
DBG(%s: marking 0x%x - 0x%lx\n, __func__,
-pg PAGE_SHIFT, start);
+pg PAGE_SHIFT, start PAGE_SHIFT);
becomes in pages here
start = PAGE_SHIFT;
while (pg MEM_AVAILABLE_PAGES pg start) {
-JX
___
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
I disagree with what this patch does. On Jan 8, 2007, at 4:03 PM, Hollis Blanchard wrote: # HG changeset patch # User Hollis Blanchard [EMAIL PROTECTED] # Date 1168293789 21600 # Node ID e1ee8b26c15de7afd7dec2d604b00d607e1307f4 # Parent dbc74db14a4b39d359365fcf8257216d968fa269 Move lots of memory logic earlier. - We now require the common boot allocator has been initialized before __start_xen(), and we use that in boot_of.c instead of managing our own. It is far more important that we do as little as possible in boot_of, just enough to know where we are and instantiate any parts of memory that need it. When we are booted with a flattened devtree (via kexec, or some other loader), we will never call into boot_of.c. The custom boot_of allocator is trivial and allows for simple tracking of available memory. Removing our custom allocator is important to simplify the upcoming multiboot2 conversion. how? - 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. - 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. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: patch flow
On Jan 3, 2007, at 12:01 PM, Hollis Blanchard wrote: 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. Unfortunately, the above patch was controversial and the rework in on my queue, but thats not the point here. 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.) I think this model is premature since the only purpose of -merge is to be a consistent pull tree. Unfortunately, -merge is incomplete, may not run or even build, we cannot base work on that. This will ensure that we never have the same difficulty staying in sync with xen-unstable that we've had in the past. I'm not sure how.. Are you asking all developers to send diffs based on the -merge tree? Are you asking the maintainers to go thru the following process? 1) apply diffs to childof-unstable, test 2) apply to childof-merge and then push -merg blind 3) pull -merge into -unstable 4) reset childof-unstable I think we need to get -unstable to a point where patches are acceptable make the tip of -merge be that snapshot and continue working in -unstable. So lets bear down and get whatever change set that is in -unstable into -merge. We can consider what you propose when -merge works completely -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [patch] multiboot2 support
On Jan 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.
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
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.
boot allocator bitmap (common Xen code)
Xen heap
...
_start (0x40; 64MB)
0x40 is 4MiB
I had a paragraph on how 64MiB was bad and then realized it is still
4MiB :)
[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;
+
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.
+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]);
Is the cast necessary?
+if (p != NULL) {
+/* Xen proper
Re: [XenPPC] [patch] multiboot2 support
On Jan 4, 2007, at 3:02 PM, Hollis Blanchard wrote:
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.
Ok, then it can wait till grub is ready and stable?
Otherwise the code does not add anything other than a new data
structure.
I thought you intended on pushing this soon?
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. :)
IIRC I agreed that defining location in the cmdline could certainly
go, but the r3,r4 pairing should stay.
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.
actually your patch in setup.c assumes the memory after _end is free
and clear, this is not the case if the OFD was placed after the image
which is certainly possible, see below.
Anyways, regardless of the exact placement (which is
subject to available), the order remains the same.
well, not really, RTAS could fit but OFD could easily be after the
image. It does now because we I made it smaller becaus SLOF/PIBS
devtrees are small. Unfortunately apple devtrees are HUGE and the
original size that we allocated (to accommodate them) cause it to
exist after the xen image.
+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));
I'm sure you have, but please don't forget to round up your allocation.
+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.
right, no tag is necessary since you have rtas_{base,end}.
+/* 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
Re: [XenPPC] xend and routes
On Dec 8, 2006, at 6:24 PM, poff wrote: We have had a couple network configuration mysteries, (including setting 'network-bridge netdev=eth0') due to CSO usage of eth1 as default/extenal adapter, rather than eth0. Probably the xen scripts would have worked without mods if eth0 1 were swapped... I think the problem is that the bridge favors the default route, so I do not think swapping would work. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xend and routes
On Dec 9, 2006, at 4:16 PM, poff wrote: BTW: If you would like to have DomUs to have access to the outside world then you also want to make sure you have ip forwarding turned on: # echo 1 /proc/sys/net/ipv4/ip_forward forever change IP_FORWARD= from no to yes in /etc/sysconfig/ sysctl 'ip forwarding' is not necessary - I think bridging handles DomU packets without involving Dom0 network stack. For CSO the other issue is ip addresses for DomUs - viz 9.2... vs 192.168... are the addresses routable or not? the following reflects my understanding of how things work, wich could be completely wrong, so here goes. you have a machine that has 2 NICs (eth0 and eth1) on 2 Networks (192.x and 9.x). If this machine would like 192.x machines to acces the 9.x network the ip_forwrding is necessary. Using the kernel-bridge you have _extended_ the eth0/192.x to the DomUs so it is no different than if it was another machine hooked into eth0. The default Xen scripts seem to have hooked the bridge onto the default route somehow and things get a little wonky. -JX ___ 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 Dec 7, 2006, at 6:16 PM, Hollis Blanchard wrote: 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? We are still being _really_ dumb about the icache and flushing it on every switch in context_switch(). -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: shutdown/destroy domU problem
Doron Shiloach/Watson/IBM wrote on 12/08/2006 10:16:29 AM: Please try executing /sbin/poweroff manually on the DomU and see if that works. (none):/ # /sbin/poweroff WARNING: could not determine runlevel - doing soft poweroff (it's better to use shutdown instead of poweroff from the command line) shutdown: /dev/initctl: No such file or directory init: /dev/initctl: No such file or directory I am using a custom init script with this domU, which from what you wrote previously, seems to not be creating a real init process, preventing the xm shutdown from working. Correct! What do you mean by a real init process? All *nix OSes have an init process PID 1, this is tha ancestor of all processes, it is the first program the the kernel runs. Typically the first program is /sbin/init, the role of this program is to run init scripts (and take in orphan processes, but thats another story) When the OS switches to several run-levels including power-off that request is communicated to the init process thru a named pipe /dev/initctl. /sbin/init will create this pipe if it detects that its PID = 1. Is it possible for me to shutdown command? Not really. Why do you need to run your own init? can't you just remove/add services and boot into single user mode? As for the xm destroy, I mean that I can use the command once (usually) , and it works, removing that domU. However, when I try to use it on a second domU, the machine freezes. From what I understand, it is preferable to use the shutdown command, so this is a secondary issue, for me at least.. Hmm.. I'd like to see this if you ever get it on a VNC please ST me -JX.. Thanks, Doron Shiloach Jimi Xenidis/Watson/IBM 12/07/2006 04:18 PM To Doron Shiloach/Watson/[EMAIL PROTECTED] cc David M Daly/Watson/[EMAIL PROTECTED], Dilma M Da silva/Watson/[EMAIL PROTECTED], Maged Michael/Watson/[EMAIL PROTECTED] Subject Re: shutdown/destroy domU problem Doron, First, these are awesome questions for the mailing list and I wish you would use it, I've asked for this time and time again. Second, when you say xm shutdown this sends a message to the DomU to execute the program /sbin/poweroff, if this command does not work then you will never shut down. Please try executing /sbin/poweroff manually on the DomU and see if that works. For example, if I try on one of our NFSROOT images with init=/bin/sh the following happens: 9:/# /sbin/poweroff Broadcast message from root (console) (Wed Dec 31 19:02:07 1969): The system is going down for system halt NOW! shutdown: timeout opening/writing control channel /dev/initctl init: timeout opening/writing control channel /dev/initctl 9:/#: and the DomU does not shut down because there is no real init process to create the /dev/intctl pipe, this is why I cannot xm shutdown this domain. If I boot the same thing but this time I do not define init but add S to the kernel parameters, init runs (but places be in single user mode) and now /sbin/poweroff runs if I run it manually or if I run it from XM. Third, I have _never_ had a problem with xm destroy and it works instantly for me and I _hate_ saying for me. What do you mean but using it a second time? The system freezing usually indicates that a DomU has panic()ed, this is currently an ourstanding bug in XenPPC but is usually only seen on UP versions. It would be news to me to see this on an SMP system. thank you http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel -JX Doron Shiloach/Watson/IBM 12/07/06 11:55 AM To Jimi Xenidis/Watson/[EMAIL PROTECTED] cc Dilma M Da silva/Watson/[EMAIL PROTECTED], David M Daly/Watson/[EMAIL PROTECTED], Maged Michael/Watson/[EMAIL PROTECTED] Subject shutdown/destroy domU problem Hi Jimi, I'm having problems with the shutdown/destroy domU functionality with the latest version of Xen that David released. Here are the versions for Xen (top) and Linux (bottom) that we are using. cso85:~/xen-maria-12-4/xen-ppc # hg tip tag: tip 19:11:02 2006 -0500 Managment workaround in the code as well so85:~/xen-maria-12-4/linux/linux-xen-ppc # hg tip 33309:f0981398b745 Mon Nov 27 13:10:34 2006 -0500 In short, the shutdown feature does not work properly; after issuing shutdown domUid, the xm list still shows the domU present. The xm destroy causes the domain to go away, but using it a second time causes the machine to freeze. Do you have time to follow this thread? Are there other people I should talk to about this? Thanks for your help, Doron Shiloach ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] xend and routes
I'm no expert on this stuff but I'll give it a try: On Dec 6, 2006, at 1:51 PM, Maria Butrico wrote: Notice that the machine name, cso89 corresponds to ip address 9.2.78.89 and is on eth1. Notice also that there is a default route from the machine, the last one, in the table above. After we start xend this is the network interface table. [snip] vif0.1Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 The vif is usually vifDomID.ethN. The vif that is selected to use is based on the original default route, but things get confused because its the wrong interface then you selected. I believe (completely by inspection) that you want to change the following in xend-config.sxp: (vif-script vif-bridge) to be: (vif-script vif-bridge vif=0) This should force the selection you want and may get the routes correct. BTW: If you would like to have DomUs to have access to the outside world then you also want to make sure you have ip forwarding turned on: # echo 1 /proc/sys/net/ipv4/ip_forward forever change IP_FORWARD= from no to yes in /etc/sysconfig/sysctl -JX ___ 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 Dec 5, 2006, at 6:20 PM, Jerone Young wrote:
This patch changes the code so can support more than one type
delimiter
on the command line. Now you can use || as well as --. ||
works
better with SLOF currently available. There is a bug in some cases
using
SLOF where -- is not treated as desired.
Patch has been tested and ready to go.
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.cTue Dec 05 17:08:41 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[] = { -- , || };
+static int sepr_index = 0;
no reason for sepr_index to be static
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,18 @@ 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
We avoid C++ comments please use /* */ and I can't believe _I_ cought
a typo :)
+for(sepr_index; sepr_index (sizeof(sepr)/sizeof(char *));
sepr_index++){
Please use ARRAY_SIZE(sepr)
+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]) - 1;
The -1 is because sizeof() includes '\0', so you can drop it here.
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Disable DPM until code is audited
thanks Amos! -JX On Dec 4, 2006, at 10:37 AM, Amos Waterland wrote: On Sat, Dec 02, 2006 at 10:31:11AM -0500, Jimi Xenidis wrote: The following patch results in SMP stability on Maple. Amos, Kawachiya-san, could one of you ack it with the JS20 in question? @@ -193,10 +193,10 @@ void cpu_initialize(int cpuid) mtdec(timebase_freq); mthdec(timebase_freq); -/* FIXME Do not set the NAP and DPM bits in HID0 until we have had a - * chance to audit the safe halt and idle loop code. */ +/* FIXME Do not set the NAP bit in HID0 until we have had a chance + * to audit the safe halt and idle loop code. */ hid0.bits.nap = 0; /* NAP */ -hid0.bits.dpm = 0; /* Dynamic Power Management */ +hid0.bits.dpm = 1; /* Dynamic Power Management */ hid0.bits.nhr = 1; /* Not Hard Reset */ hid0.bits.hdice_en = 1; /* enable HDEC */ This works on the JS20 in TRL. Acked-by: Amos Waterland [EMAIL PROTECTED] ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Disable DPM until code is audited
On Dec 2, 2006, at 2:37 AM, Segher Boessenkool wrote: Do not set the NAP and DPM bits in HID0 until we have had a chance to audit the safe halt and idle loop code. Not setting these bits allows the model 884241X JS20 blade in TRL to boot correctly, and possibly also the Maple in YKT. Thanks to Jimi for his help in this matter. Is the DPM change required? I never saw any problems here... NAP and other power saving modes can cause problems for sure (for example, on pre-970MP 970s, some power saving modes require flushing the L2 before entering that mode, etc.) Most JS20 and JS21 have DPM disabled on the board, What does this mean? SLOF/js2x enables DPM always, for example; there is no hardware override that I'm aware of. According to S9.9 of 970FX UM: Dynamic power management can be disabled in the RAS units by asserting bit[0] in the JTAG register with modifier address 0x000800. which is why we have not seen any SMP problems with them. However the Maple-D and the JS20 model Amos cites both have had problems with the one of these two modes. That model seems to be the newest JS20 we've run on. Sounds like the problem manifests itself on all 970FX and no other CPUs from the 970 family. I was under the impression that we had other 970FX js20s but perhaps we do not We'll have to brush up on errata before we enable this one again. Yeah; errata and other chip differences. My question remains: did you try with NAP disabled and DPM enabled? I see, so: HID0[NAP]=1 HID0[DPM]=1 MSR[POW]=1 is NAP and is different than: HID0[NAP]=0 HID0[DPM]=1 MSR[POW]=1 which is something else? Sure I'll try that. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Disable DPM until code is audited
On Dec 2, 2006, at 10:18 AM, Jimi Xenidis wrote: On Dec 2, 2006, at 2:37 AM, Segher Boessenkool wrote: My question remains: did you try with NAP disabled and DPM enabled? I see, so: HID0[NAP]=1 HID0[DPM]=1 MSR[POW]=1 is NAP and is different than: HID0[NAP]=0 HID0[DPM]=1 MSR[POW]=1 which is something else? Sure I'll try that. The following patch results in SMP stability on Maple. Amos, Kawachiya-san, could one of you ack it with the JS20 in question? diff -r 0e85b389980a xen/arch/powerpc/powerpc64/ppc970.c --- a/xen/arch/powerpc/powerpc64/ppc970.c Fri Dec 01 19:11:02 2006 -0500 +++ b/xen/arch/powerpc/powerpc64/ppc970.c Sat Dec 02 10:26:50 2006 -0500 @@ -193,10 +193,10 @@ void cpu_initialize(int cpuid) mtdec(timebase_freq); mthdec(timebase_freq); -/* FIXME Do not set the NAP and DPM bits in HID0 until we have had a - * chance to audit the safe halt and idle loop code. */ +/* FIXME Do not set the NAP bit in HID0 until we have had a chance + * to audit the safe halt and idle loop code. */ hid0.bits.nap = 0; /* NAP */ -hid0.bits.dpm = 0; /* Dynamic Power Management */ +hid0.bits.dpm = 1; /* Dynamic Power Management */ hid0.bits.nhr = 1; /* Not Hard Reset */ hid0.bits.hdice_en = 1; /* enable HDEC */ ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] FYI: [Xen-devel] FW: Request for Xen console device (xvc0)
Amos, you see this? Begin forwarded message: From: Keir Fraser [EMAIL PROTECTED] Date: November 29, 2006 6:31:34 AM EST To: Xen-devel [EMAIL PROTECTED] Subject: [Xen-devel] FW: Request for Xen console device (xvc0) Lanana has provided an xvc0 allocation, so I'll apply a patch to add this as an option to the console driver. -- Keir -- Forwarded Message From: Mathiasen, Torben [EMAIL PROTECTED] Date: Wed, 29 Nov 2006 11:58:02 +0100 To: Keir Fraser [EMAIL PROTECTED] Conversation: Request for Xen console device (xvc0) Subject: RE: Request for Xen console device (xvc0) Please can we be allocated a major/minor for the following new device: /dev/xvc0Xen virtual console - port 0 This has been added to lanana.org with major/minor 204/191. Please verify the data is correct. Thanks, Torben -- End of Forwarded Message ___ Xen-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [xenppc-unstable] [XEN][POWERPC] SMP/IPI/MB combined
On Nov 28, 2006, at 1:37 AM, Amos Waterland wrote:
This will have to be reworked and broken up into individual parts for
submission, but here is what is necessary to make 'C-a C-a C-a t' work
properly.
Jimi, when you disassemble xen-syms compiled without this patch, do
you
see a bogus infinite loop in read_clocks?
looked briefly but did not notice it.
The compiler is not told that
read_clocks_cpumask is volatile, so it is free to turn that loop
into an
infinite loop, as my gcc 4.1.1 cross-compiler does. I am surprised
that
other Xen architectures have not seen the same problem.
Found it, cpu_relax() is supposed to contain barrier() call.
My fault but it coulda been hollis :)
diff -r cc45282daf3d xen/include/asm-powerpc/processor.h
--- a/xen/include/asm-powerpc/processor.h Mon Nov 27 17:17:07 2006 -0500
+++ b/xen/include/asm-powerpc/processor.h Tue Nov 28 10:19:09 2006 -0500
@@ -152,7 +152,7 @@ static inline void nop(void) {
static inline void nop(void) {
__asm__ __volatile__ (nop);
}
-#define cpu_relax() nop()
+#define cpu_relax() barrier()
static inline unsigned int mfpir(void)
{
this will solve the volatile issue and am pushing this now.
more below..
arch/powerpc/smp.c| 18 ++
common/keyhandler.c |2 +-
include/xen/cpumask.h |2 +-
3 files changed, 12 insertions(+), 10 deletions(-)
diff -r 305751a5281e xen/arch/powerpc/smp.c
--- a/xen/arch/powerpc/smp.cWed Nov 22 16:29:25 2006 -0500
+++ b/xen/arch/powerpc/smp.cTue Nov 28 00:45:24 2006 -0500
@@ -91,31 +91,33 @@ int on_selected_cpus(
int wait)
{
int t, retval = 0, nr_cpus = cpus_weight(selected);
+int stall = timebase_freq * 10;
spin_lock(call_lock);
call_data.func = func;
call_data.info = info;
call_data.wait = wait;
-call_data.wait = 1; /* Until we get RCU around call_data. */
atomic_set(call_data.started, 0);
atomic_set(call_data.finished, 0);
mb();
send_IPI_mask(selected, CALL_FUNCTION_VECTOR);
-/* We always wait for an initiation ACK from remote CPU. */
-for (t = 0; atomic_read(call_data.started) != nr_cpus; t++) {
-if (t t % timebase_freq == 0) {
-printk(IPI start stall: %d ACKS to %d SYNS\n,
- atomic_read(call_data.started), nr_cpus);
-}
+/* If told to, we wait for an initiation ACK from remote CPU. */
+if (wait) {
+ for (t = 0; atomic_read(call_data.started) != nr_cpus; t++) {
+ if (t 0 t % stall == 0) {
+ printk(IPI start stall: %d ACKS to %d SYNS\n,
+ atomic_read(call_data.started), nr_cpus);
+ }
+ }
you _always_ have to wait for call_data.started it means that its
safe to reuse call_data.
}
/* If told to, we wait for a completion ACK from remote CPU. */
if (wait) {
for (t = 0; atomic_read(call_data.finished) != nr_cpus; t+
+) {
-if (t timebase_freq t % timebase_freq == 0) {
+if (t 0 t % stall == 0) {
printk(IPI finish stall: %d ACKS to %d SYNS\n,
atomic_read(call_data.finished), nr_cpus);
}
diff -r 305751a5281e xen/common/keyhandler.c
--- a/xen/common/keyhandler.c Wed Nov 22 16:29:25 2006 -0500
+++ b/xen/common/keyhandler.c Tue Nov 28 00:12:14 2006 -0500
@@ -193,7 +193,7 @@ static void dump_domains(unsigned char k
read_unlock(domlist_lock);
}
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] multicast function invocations
On Nov 28, 2006, at 3:17 AM, Amos Waterland wrote: To summarize the situation, I found two problems. 1. Core Xen has a bug (I believe) in which they do not mark their cpu mask volatile, so the compiler generates an infinite loop in read_clocks. I will send some patches upstream to resolve this issue. This was PPc specific bug covered by: # HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID a8e67a19c3255a6bbc0aaa5c9e1736f1ddd76f6c # Parent cc45282daf3d242fdcf6e858c0b18b7f1086a318 cpu_relax() needs to call barrier() 2. Xen/PPC has a problem in that its IPI callbacks (remote function invocations) do not actually happen in parallel, which breaks the design of read_clocks. Our IPI callbacks are serialized by the design we copied from Xen/x86, which is to acquire a per-vector lock very early in the EE handling path (see do_external). I guess my real question is: will Xen/PPC ever in the future run its IPI remote function callbacks with EE enabled? If the plan is to keep things the way they are now, then we should remove the per-vector lock entirely. The lock protects the vector handler which theoretically could be reprogramed. However we should not be calling the action with the lock held unless its per-cpu The following is a patch that implements the above two conclusions and which allows 'C-aC-aC-at' to work properly. Comments? --- arch/powerpc/external.c |2 -- common/keyhandler.c |2 +- include/xen/cpumask.h |2 +- 3 files changed, 2 insertions(+), 4 deletions(-) diff -r 305751a5281e xen/arch/powerpc/external.c --- a/xen/arch/powerpc/external.c Wed Nov 22 16:29:25 2006 -0500 +++ b/xen/arch/powerpc/external.c Tue Nov 28 03:07:10 2006 -0500 @@ -86,11 +86,9 @@ void do_external(struct cpu_user_regs *r /* do_IRQ is fundamentally broken for reliable IPI delivery. */ irq_desc_t *desc = irq_desc[vec]; regs-entry_vector = vec; -spin_lock(desc-lock); desc-handler-ack(vec); desc-action-handler(vector_to_irq(vec), desc-action- dev_id, regs); desc-handler-end(vec); -spin_unlock(desc-lock); Please add a: BUG_ON(!(desc-status IRQ_PER_CPU)); If you trip this then we will need: - locking around the desc - tickle some status bits - unlock the action - lock again - tickle status bits. ... ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Fix IPI stall timeout
On Nov 28, 2006, at 5:55 PM, Amos Waterland wrote:
When using the register dump feature of Xen, one will sometimes see a
message about an IPI finish stall. This is because of an int to long
comparison bug, so fix it by doing proper nanosecond based time
accounting.
As a side note, our IPI remote function call latency of completion on
a JS21 blade is: min = 34 ticks, max = 119 ticks, mean = 2691ns.
Signed-off-by: Amos Waterland [EMAIL PROTECTED]
---
smp.c | 39 +--
1 file changed, 25 insertions(+), 14 deletions(-)
diff -r e01e08ca629b xen/arch/powerpc/smp.c
--- a/xen/arch/powerpc/smp.cTue Nov 28 17:01:00 2006 -0500
+++ b/xen/arch/powerpc/smp.cTue Nov 28 17:40:50 2006 -0500
@@ -90,7 +90,8 @@ int on_selected_cpus(
int retry,
int wait)
{
-int t, retval = 0, nr_cpus = cpus_weight(selected);
+int retval = 0, nr_cpus = cpus_weight(selected);
+unsigned long start, stall = tb_to_ns(timebase_freq);
Since you are using NOW(), this should have nothing to do with timebase.
so should be
unsigned long start, stall = SECONDS(1);
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] xc_get_pfn_list() creates broken core files
On Nov 23, 2006, at 5:05 PM, John Levon wrote: On Thu, Nov 23, 2006 at 08:52:57PM +, John Levon wrote: How about the below. For now I've disabled HVM dumps until this interface exists, but it should be ready to go. Ugh, not that simple. We need to use max_pfn not nr_pages. Presumably HVM domains have an accurate shared_info? And what do we do for ia64/ppc? In PPC we are still using xc_get_pfn_list() and moving towards a p2m like data structure, but we are hoping to have something better than an array of 4k entries, since we track memory at a larger granularity. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [xenppc-unstable] [XEN][POWERPC] SMP/IPI/MB combined
On Nov 22, 2006, at 3:01 PM, Xen patchbot-xenppc-unstable wrote: # HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID ea41ccaa8d77134b8fb55e8b002d358e67c47152 # Parent ce8c1e26b2aebd64c8a2f02e20ed46d587f42870 [XEN][POWERPC] SMP/IPI/MB combined After pushing this patch I when to fix/update some ^A^A^A commands which I did. Amos, it seems that: (XEN) key 't' (ascii '74') = display multi-cpu clock info has problems. I filed a bug to cover this: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=820 -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [linux-ppc-2.6] [XEN][POWERPC] HYPERVISOR_memory_op() return value now has meaning
Yi noticed that we could not build domains with memory beyond the RMA.
This Linux patch fixes that.
-JX
On Nov 14, 2006, at 7:44 PM, Xen patchbot-linux-ppc-2.6 wrote:
# HG changeset patch
# User Jimi Xenidis [EMAIL PROTECTED]
# Node ID 47cd37e8f8a91bdf10b314cbaa8d5a9088be30fc
# Parent 01f3c63f0343051ce1cc039b4bd38def61eb3def
[XEN][POWERPC] HYPERVISOR_memory_op() return value now has meaning
This patch fixes a false failure when calling HYPERVISOR_memory_op()
from user space, where the return value fromt he hcall is expected.
With this fix, the recent bits can can create domains beyond their
RMA.
Signed-off-by: Jimi Xenidis [EMAIL PROTECTED]
---
arch/powerpc/platforms/xen/hcall.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -r 01f3c63f0343 -r 47cd37e8f8a9 arch/powerpc/platforms/xen/
hcall.c
--- a/arch/powerpc/platforms/xen/hcall.c Sat Nov 11 10:25:31 2006
-0500
+++ b/arch/powerpc/platforms/xen/hcall.c Tue Nov 14 19:33:36 2006
-0500
@@ -520,7 +520,8 @@ static int xenppc_privcmd_memory_op(priv
sizeof(xen_memory_reservation_t)))
return -EFAULT;
- if (!HYPERVISOR_memory_op(cmd, kern_op)) {
+ ret = HYPERVISOR_memory_op(cmd, kern_op);
+ if (ret = 0) {
if (copy_to_user(user_op, kern_op,
sizeof(xen_memory_reservation_t)))
return -EFAULT;
___
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] [PATCH] SMP/IPI/ERAT/MB combined
On Nov 9, 2006, at 8:04 PM, Amos Waterland wrote: This patch rolls up and rebases the following patches for submission against current tip of tree: * Memory barrier after sp store * Flush the ERAT early for secondary CPUs * SMP and IPI support Signed-off-by: Amos Waterland [EMAIL PROTECTED] So I applied this patch to the merge of: changeset: 12997:4589b3dec1fd tag: tip And it applied with one small reject that was easy to solve. I also applied it to: changeset: 12469:b30cb72ed5e2 Which was the rev before Fridays big merge. Good News: On both I can run several domains, many more that I have physical CPUs with all sorts of VIO combos. Bad News: Testing on my JS21 with 4 CPUs, when I try to dump the registers for the xen console (after a ^A*3) I get: (XEN) 'd' pressed - dumping registers (XEN) (XEN) *** Dumping CPU0 state: *** (XEN) [ Xen-3.0-unstable ] (XEN) CPU: DOMID: 7fff (XEN) pc msr (XEN) lr ctr (XEN) srr0 srr1 (XEN) r00: 0043c660 (XEN) r04: (XEN) r08: (XEN) r12: (XEN) r16: (XEN) r20: (XEN) r24: (XEN) r28: (XEN) --- HANG for 3 minutes (wall clock) (XEN) *** Dumping CPU1 state: *** (XEN) IPI start stall: 0 ACKS to 1 SYNS (XEN) IPI start stall: 0 ACKS to 1 SYNS (XEN) IPI start stall: 0 ACKS to 1 SYNS Oddly enough, If I boot with sync_console there is no HANG of any time. Does this work for you? Anyways, I cannot accept this patch if '^A*3 d' does not work, it is too important for development. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Remapping xenheap pages into dom0.
Tony, Yes you are getting Kernel pages. On Nov 13, 2006, at 12:47 AM, Tony Breeds wrote: Howdy all, I'm having problems getting what should be a reasonably fundamental operation working. I have a set of xenheap pages that I'm initialising and then attempting to map in to dom0 (This is for hcall tracing [ xen/common/trace.c ]) [SNIP] Does anyone have any ideas on what I can look at to work out why I'm not getting that page I think I should be getting? Does anyone have any ideas on what I can look at to work out why I'm not getting that page I think I should be getting? You are on the verge of discovering a dirty little secret. Currently our PFN (aka Guest MFN or GMFN) to MFN translation is pretty messy. This all comes down to the fact that our PTE entry hypercall (H_ENTER) has not mechanism to say that the PFN is actually an MFN. Much of the hacker is explained in pfn2mfn() in the Xen code. The only reason Dom0 is currently able to map an MFN belonging to a new domain is that when you use that MFN as a PFN it is greater than Dom0's Largest PFN and we let you map the MFN dirrectly because you are Dom0. The problem you are having is that Xen Heap pages all have MFNs that are below even Dom0's MFN, and therefore will not get trapped by the hack above. So yes, you are simply remapping your own dom0 memory. What we have been doing to get around this is decorating the PFN with a high order bit in such a way that Xen can recognize the PFN as (Magic Bit | MFN) and map it. Dan and Yi are using (1UL34 [I think]) to decorate Dom0 apps access to the HTAB of a suspending domain, also more Xen heap pages. The grant tables (mappable by all doamins) are more xen heap pages that need decorating, where I'm currently using the page after max_page. Complicating this even further is that we need a foreign page area (Magic bit == 1UL22) to allow for granted memory to be mapped by the grantee. Its dirty, stinky and sucks, but its what we have at the moment until we spend the time to unify it all somehow. Take a look at Dan and Yi's patch you should be able to reuse their decoration: http://lists.xensource.com/archives/html/xen-ppc-devel/2006-11/ msg00028.html NOTE: this patch is still under review. Also, this may or may not be related. If I don't call down to share_xen_page_with_guest() I would have expected to get some form of oops or crash, but the machine exhibits the same behavior. Actually that probably indicates that I'm getting a kernel pages rather than xen page. All share_xen_page_with_guest() seems to do is mark a XenHeap page as used by a domain for accounting purposes and debugging. Am not surprised it makes no difference. ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [linux-ppc-2.6] [XEN][POWERPC] Use a bitmap to manage the foreign page area
Thanks for the watchful eye
On Nov 9, 2006, at 4:49 PM, Muli Ben-Yehuda wrote:
On Thu, Nov 09, 2006 at 12:02:45AM +, Xen patchbot-linux-
ppc-2.6 wrote:
+struct page *alloc_foreign_page(void)
+{
+ int bit;
+ do {
+ bit = find_first_zero_bit(foreign_map_bitmap,
+ foreign_map_pgs);
bit should be 'unsigned long'.
ACK
+ if (bit = foreign_map_pgs)
+ return NULL;
I would print a message that the allocator has been exhausted here -
it's a common source of bugs.
I'd prefer that in the caller report this, like any other allocator.
Also, tiny optimization, but perhaps you
next fit rather than first fit?
What is the optimization here? Some arches _do_ have different
implementation for the 2, on PPC I would save a #define.
If you are suggesting I try to find the next zero bit if the first
attempt does not work, I was thinking of that and IMHO the
optimization is just not worth even the that trivial complication
since we are only allocating on dev/mod init and freeing on dev/mod
fini.
+ } while (test_and_set_bit(bit, foreign_map_bitmap) == 1);
+
+ return pfn_to_page(foreign_map_pfn + bit);
+}
+
+void free_foreign_page(struct page *page)
+{
+ int bit = page_to_pfn(page) - foreign_map_pfn;
+
+ BUG_ON(bit 0);
+ BUG_ON(bit = foreign_map_pgs);
I would add BUG_ON(!test_bit(bit, foreign_map_bitmap)) here to catch
another common source of bugs.
ACK
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [linux-ppc-2.6] [XEN] The VIO rewrite
On Nov 5, 2006, at 11:18 PM, Tony Breeds wrote: On Fri, Nov 03, 2006 at 10:02:41PM +, Xen patchbot-linux- ppc-2.6 wrote: # HG changeset patch # User Jimi Xenidis [EMAIL PROTECTED] # Node ID 2a9c6a23cd1292e9ed361e33d640ce84a6fbdb53 # Parent f4d382795e57b926cd82256bcb3a74c539731796 [XEN] The VIO rewrite [snip] I gave the newtwork tests a spin with this patch. After 4 hours I stopped the tests. I see a bunch of these warnings on the xen console. --- (XEN) allocated RMA for Dom[13]: 0x1800[0x400] (XEN) Domain[13].0: initializing (XEN) WARN at /home/tony/Xen/xenppc-unstable.hg.working/xen/include/ asm/mm.h:262 (XEN) [F8A0] 0040D8B4 .gmfn_to_mfn+0x70/0xa4 Ok, This happens because a foreign map might have been unmapped to early, I saw this early on, but thought I nailed it. guess not. On the bright side, asside from the fact the tests are taking a long time, at least some of them are succeeding. --- Blade4:~/xm-test # egrep '(PASS|FAIL|SKIP)' network_vio.output XFAIL: 02_network_local_ping_pos.test PASS: 03_network_local_tcp_pos.test PASS: 04_network_local_udp_pos.test XPASS: 05_network_dom0_ping_pos.test PASS: 06_network_dom0_tcp_pos.test PASS: 07_network_dom0_udp_pos.test XFAIL: 11_network_domU_ping_pos.test FAIL: 12_network_domU_tcp_pos.test FAIL: 13_network_domU_udp_pos.test --- Is there a difference between PASS and XPASS? I tried runnig quick and it took a long time, the system was unresponsive. much like: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=727 I really need to get to the bottom tod that one. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [linux-ppc-2.6] [XEN] The VIO rewrite
On Nov 8, 2006, at 9:57 AM, Jimi Xenidis wrote: On Nov 4, 2006, at 12:35 PM, poff wrote: Here's this patch on JS20, with 192mb Dom0, 512mb total: Hmm, so a 512MiB machine? arch_gnttab_map: grant table at d80082016000 setup_grant_area: mempool_create(): failed kernel BUG in setup_grant_area at /home/poff/linux-ppc-2.6-work.hg/ arch/powerpc/platforms/xen/gnttab.c:420! cpu 0x0: Vector: 700 (Program Check) at [c0a3fa50] pc: c0043fc0: .arch_gnttab_map+0x1bc/0x254 lr: c0043fbc: .arch_gnttab_map+0x1b8/0x254 sp: c0a3fcd0 msr: 80028032 current = 0xc0a31800 paca= 0xc052e300 pid = 1, comm = swapper kernel BUG in setup_grant_area at /home/poff/linux-ppc-2.6-work.hg/ arch/powerpc/platforms/xen/gnttab.c:420! enter ? for help 0:mon Hmm, ok.. I wonder why it failed? I'm such a lazy @ss when I use BUG() all the time, I really did not expect mempool to ever have a memory issue. I'll see if I can replicate by forcing my dom0 to this size. Hmm.. I capped my Dom0 to 192M and 64M and it worked fine. The only reason that mempool_create() can fail is if an underlying kmalloc failed, I don't think that we are trying to get so much memory. Hey! did you update Xen as well? because the number of pages was way too large before. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
VIO rewrite Was: FYI: Re: [XenPPC] problem of ssh to domU on js21
!!! NOTE: please update both linux and xen. Hao, Thank you for you patience with all this networking stuff. I've reworked the entire VIO stuff in Xen and Linux. It has fixed all the VIO Network stability problems that I have been experiencing hopefully it will fix yours as well. With these changes, I am able to run several DomUs with: - nfsroot - ip=dhcp - scp -r large directories with large files - ssh session with lots of output. Please test when you can. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Experimental patch that get more networking but still buggy.
2 patches that need to be applied one after the other.
netback works for a little longer, but it is still buggy.
Any feedback on this is good.
-JX
===
diff -r f4d382795e57 arch/powerpc/platforms/xen/gnttab.c
--- a/arch/powerpc/platforms/xen/gnttab.c Wed Oct 25 17:22:54 2006 -0400
+++ b/arch/powerpc/platforms/xen/gnttab.c Fri Oct 27 15:39:57 2006 -0500
@@ -25,6 +25,33 @@ static ulong foreign_map_base;
static ulong foreign_map_base;
static ulong foreign_map_end;
+
+/* hijack _mapcount */
+static inline int gnt_mapcount(struct page *page)
+{
+ return atomic_read((page)-_mapcount) + 1;
+}
+
+static inline int gnt_map(struct page *page)
+{
+ /* return true is transition from -1 to 0 */
+ return atomic_inc_and_test(page-_mapcount);
+}
+
+static inline int gnt_unmap(struct page *page)
+{
+ int val;
+
+ val = atomic_dec_return(page-_mapcount);
+ if (val -1) {
+ atomic_inc(page-_mapcount);
+ printk(KERN_EMERG %s: %d\n, __func__, val);
+ }
+
+ return (val == -1);
+}
+
+
static long map_to_linear(ulong paddr)
{
unsigned long vaddr;
@@ -136,21 +163,20 @@ static void gnttab_pre_unmap_grant_ref(
int i;
ulong ea;
unsigned long dummy1, dummy2;
+ ulong flags;
+
+ /* paranoia */
+ local_irq_save(flags);
for (i = 0 ; i count; i++) {
struct page *page;
ea = unmap[i].host_addr;
page = virt_to_page(ea);
-
- /* Unfortunately, there is no put_page_testone() like
-* put_page_testzero(). The Linear Map starts all
-* pages with a count of 1, so there may be SMP issues
-* here. */
-
- put_page(page);
- if (page_count(page) 1) {
- DBG(%s: skip: 0x%lx\n, __func__, ea);
+
+ if (!gnt_unmap(page)) {
+ DBG(%s[0x%x]: skip: 0x%lx, mapcount 0x%x\n,
+ __func__, i, ea, gnt_mapcount(page));
continue;
}
slot = find_map_slot(ea);
@@ -160,10 +186,11 @@ static void gnttab_pre_unmap_grant_ref(
continue;
}
- DBG(%s: 0x%lx: page count: 0x%x\n,
- __func__, ea, page_count(virt_to_page(ea)));
+ DBG(%s[0x%x]: 0x%lx: mapcount: 0x%x\n,
+ __func__, i, ea, gnt_mapcount(page));
plpar_pte_remove(0, slot, 0, dummy1, dummy2);
}
+ local_irq_restore(flags);
}
static void gnttab_post_map_grant_ref(
@@ -171,6 +198,10 @@ static void gnttab_post_map_grant_ref(
{
int i;
long slot;
+ ulong flags;
+
+ /* paranoia */
+ local_irq_save(flags);
for (i = 0 ; i count; i++) {
ulong pa = map[i].dev_bus_addr;
@@ -182,10 +213,7 @@ static void gnttab_post_map_grant_ref(
map[i].host_addr = (ulong)__va(pa);
page = virt_to_page(map[i].host_addr);
- DBG(%s: 0x%lx: 0x%x\n,
- __func__, pa, page_count(page));
-
- if (page_count(page) == 1) {
+ if (gnt_map(page)) {
#ifdef DEBUG
/* we need to get smarted than this */
slot = find_map_slot((ulong)__va(pa));
@@ -195,11 +223,15 @@ static void gnttab_post_map_grant_ref(
}
#endif
slot = map_to_linear(pa);
+ DBG(%s[0x%x]: 0x%lx, mapcount:0x%x\n,
+ __func__, i, pa, gnt_mapcount(page));
+
} else {
- DBG(%s: skip 0x%lx\n, __func__, pa);
- }
- get_page(page);
- }
+ DBG(%s[0x%x] skip 0x%lx, mapcount:0x%x\n,
+ __func__, i, pa, gnt_mapcount(page));
+ }
+ }
+ local_irq_restore(flags);
}
int HYPERVISOR_grant_table_op(unsigned int cmd, void *op, unsigned int count)
diff -r f4d382795e57 drivers/xen/netback/netback.c
--- a/drivers/xen/netback/netback.c Wed Oct 25 17:22:54 2006 -0400
+++ b/drivers/xen/netback/netback.c Fri Oct 27 15:54:04 2006 -0500
@@ -84,6 +84,9 @@ static inline void update_mmap_pages(
unsigned int idx, gnttab_map_grant_ref_t *mop)
{
struct page *p;
+
+ p = pfn_to_page(mop-dev_bus_addr PAGE_SHIFT);
+
#ifdef PPC_NOT_YET
struct page *cp = mmap_pages[idx];
extern int arch_is_foreign_page(struct page *page);
@@ -97,11 +100,9 @@ static inline void update_mmap_pages(
// __free_page(mmap_pages[idx]);
}
+ printk(KERN_EMERG %s insert[%d]: %p, 0x%x\n,
+ __func__, idx, __va(mop-dev_bus_addr), page_count(p));
#endif
- p = pfn_to_page(mop-dev_bus_addr PAGE_SHIFT);
-
- DPRINTK(KERN_EMERG
[XenPPC] Re: [Xen Wiki] Update of XenPPC/Run by JeroneYoung
First, I really appreciate you updating the wiki, I think its awesome!
On Oct 31, 2006, at 4:24 PM, [EMAIL PROTECTED] wrote:
+ === Example ===
+ Have a machine with Linux install on /dev/hda3. We do not have
any parameters to pass to the Xen hypervisor. So once
+ SLOTH firmware loads up. You will PXE boot the Xen image built
(no command line paramters specified in the build) and specify the
parameters on here:
What do you mean PXE boot? I think this is an intel/x86 world term.
This is a standard Open Firmware command:
boot device params
Specifically, (assuming you have not defined the file, IP
configuration, and TFTP server) in this case you will be TFTPing the
image that that a BOOTP packet tells net1 to load
+ {{{
+ boot net1 xen -- root=/dev/hda3
+ }}}
+ ! - note the word xen is placed as the parameter for the
Hypervisor because you cannot have no parameter, so just put
somehting that will just be dropped.
Is this _still_ true? I think at some point Xen actually wanted to
see this string to verify that the person actually wanted to boot Xen
and has since been removed. You should be able to boot without it,
if not we need to find out why.
-JX
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
Re: FYI: Re: [XenPPC] problem of ssh to domU on js21
Thanks Hao, I'm able to reproduce this. The only reason we can actually use anything is because networking is S forgiving. I think I have the solution to this, it will require some re-writing which should get done by the end of the week. BTW: you should have gotten lines like: (XEN) (file=grant_table.c, line=356) Bad handle (2). (XEN) (file=grant_table.c, line=356) Bad handle (13). (XEN) (file=grant_table.c, line=356) Bad handle (6). gnt_unmap: -2 (XEN) (file=grant_table.c, line=356) Bad handle (16). gnt_unmap: -2 (XEN) (file=grant_table.c, line=356) Bad handle (2). out of the machine console, do you see those as well? Thanks. -JX On Nov 1, 2006, at 12:18 PM, Hao Yu wrote: Hi, Here is backtrace message from the 0.mon console 0:mon t [c06ab530] c02dbf7c .network_tx_buf_gc+0x11c/0x2f0 (unreliable) [c06ab610] c02deed4 .netif_int+0x54/0x120 [c06ab6b0] c008b824 .handle_IRQ_event+0x84/0x100 [c06ab750] c008ba70 .__do_IRQ+0x1d0/0x2b0 [c06ab810] c02c777c .evtchn_do_upcall+0x11c/0x170 [c06ab8d0] c00445a0 .xen_get_irq+0x10/0x30 [c06ab950] c000bf10 .do_IRQ+0x70/0x100 [c06ab9d0] c00041ec hardware_interrupt_entry+0xc/0x10 --- Exception: 501 (Hardware Interrupt) at c003bcc0 .plpar_hcall_norets+0x10/0x1c [link register ] c0045534 .HYPERVISOR_sched_op+0x124/0x150 [c06abcc0] c05a06e0 (unreliable) [c06abd70] c004609c .xen_power_save+0x7c/0xa0 [c06abdf0] c0012060 .cpu_idle+0xe0/0x150 [c06abe70] c00095dc .rest_init+0x3c/0x60 [c06abef0] c052d958 .start_kernel+0x278/0x2e0 [c06abf90] c00084fc .start_here_common+0x50/0x54 0:mon X Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=32 Modules linked in: NIP: C02DBFB0 LR: C02DBF8C CTR: C02DEE80 REGS: c06ab2b0 TRAP: 0300 Not tainted (2.6.17-Xen) MSR: 80001432 ME,IR,DR CR: 2882 XER: 6005 DAR: 00C2, DSISR: 4000 TASK = c05748a0[0] 'swapper' THREAD: c06a8000 CPU: 0 GPR00: C06AB530 C06A9718 C0003FFB9678 GPR04: C071B5D8 C06AB510 GPR08: 0003 D8008000 00C2 GPR12: 80009032 C0575100 GPR16: C0003FFB8000 GPR20: C0568100 C0003FFB8670 0004 004C GPR24: 0048 0020 0002 004B GPR28: 0004 C0003FFB9680 C05FB020 C0003FFB8500 NIP [C02DBFB0] .network_tx_buf_gc+0x150/0x2f0 LR [C02DBF8C] .network_tx_buf_gc+0x12c/0x2f0 Call Trace: [C06AB530] [C02DBF7C] .network_tx_buf_gc+0x11c/0x2f0 (unreliable) [C06AB610] [C02DEED4] .netif_int+0x54/0x120 [C06AB6B0] [C008B824] .handle_IRQ_event+0x84/0x100 [C06AB750] [C008BA70] .__do_IRQ+0x1d0/0x2b0 [C06AB810] [C02C777C] .evtchn_do_upcall+0x11c/0x170 [C06AB8D0] [C00445A0] .xen_get_irq+0x10/0x30 [C06AB950] [C000BF10] .do_IRQ+0x70/0x100 [C06AB9D0] [C00041EC] hardware_interrupt_entry+0xc/ 0x10 --- Exception: 501 at .plpar_hcall_norets+0x10/0x1c LR = .HYPERVISOR_sched_op+0x124/0x150 [C06ABCC0] [C05A06E0] 0xc05a06e0 (unreliable) [C06ABD70] [C004609C] .xen_power_save+0x7c/0xa0 [C06ABDF0] [C0012060] .cpu_idle+0xe0/0x150 [C06ABE70] [C00095DC] .rest_init+0x3c/0x60 [C06ABEF0] [C052D958] .start_kernel+0x278/0x2e0 [C06ABF90] [C00084FC] .start_here_common+0x50/0x54 Instruction dump: 809d000c 387f1178 4bfec5c9 6000 3800 397a00c0 901d000c 6000 e93f0170 7d35c92a fb9f0170 7c2004ac 7c005828 3000 7c00592d 40c2fff4 0Kernel panic - not syncing: Fatal exception in interrupt 0Rebooting in 180 seconds.. Hao Yu Jimi Xenidis [EMAIL PROTECTED] .com To Hao Yu/Watson/[EMAIL PROTECTED] 11/01/2006 12:01 cc PMxen-ppc- [EMAIL PROTECTED] Subject FYI: Re: [XenPPC] problem of ssh to domU on js21 Thank you Hao for posting the issue to the list! I'll be posting this highly experimental patch to the list shortly. -JX On Nov 1, 2006, at 11:55 AM, Hao Yu wrote: With Jimi's new patch, the ping works fine, lasting forever (stayed
Re: [XenPPC] Timeout in the past
On Oct 31, 2006, at 3:34 AM, Amos Waterland wrote: I have seen this on a Maple now as well: (XEN) reprogram_timer[00] Timeout in the past 0x0038879D3833 0x0038879CF88C (XEN) reprogram_timer[00] Timeout in the past 0x003887AE47A4 0x003887AD2018 This usually indicates a problem somewhere. In this case we tried to set a timer about 432ms in the past (assuming 175MHz which is what my maple runs at). We should stick a WARN() or stack trace back in ths if in reporgram_timer() to figure out which timer it is. We may just need out own definition of TIMER_SLOP? -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] RFC: PowerPC and VIO
Well, we've had some success good success with VIO on PowerPC. We have had to reintroduce some P2V-like stuff to get it going, because the PowerPC is a very different beast WRT grant tables. Now that I understand it a little better I think we can re-work to remove some of the hacks we put in. Immediate questions do come to mind: Why do we return the MFN on a GNTTABOP_map_grant_ref? Shouldn't that all be hidden? I use it now, but can I depend on it in the future? I'll have more to discuss soon as I have more code. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: 2 questions of creating domU
On Oct 25, 2006, at 8:10 AM, Hao Yu wrote: Jimi, Thanks to David who put matched xen tools in the xen/linux image, which solves the problem of memory configuration. Thats good. I still can not set IP address from dhcp. For convenience, I post the configuration file here (See attached file: hao_edi_config); ifconfig output of dom0 after 'xend' started: (See attached file: ifconfig.out) ; and error message : Error: Device 0 (vif) could not be connected. Backend device not found. I wonder if there is other environment setting we need to follow ? lib path, command path ? this just works in my local disk environment and I'm pretty sure othe local disk environments work as well. Hollis, Tony are you able to create domain that have net access? I have to say that this Linux/XM device config is not really my current expertise, someone has to figure it out and know it. I'll try when I get some time unless someone else get to it first, until then please be our expert :) This may be a good question for [EMAIL PROTECTED] proper. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] [PATCH] Enable SMP and IPIs
On Oct 24, 2006, at 12:22 AM, Amos Waterland wrote:
This patch enables SMP and IPIs. It works reliably on JS20 and JS21
blades. It is not quite ready for submission, but I would greatly
appreciate any comments.
Note that the flurry of IPIs generated by domain creation seems to
be a
waste of time. Xen on x86 doesn't actually to do anything in response
to them, so I have made Xen on PPC properly deliver the event check
but
then do nothing as well. Comments?
The important thing this patch is missing is the ability to invoke
functions on a remote CPU, and I have left it out because I am not yet
happy with the convention, which is to grab a lock, put the target
address in a single global shared variable, invoke a memory
barrier, and
send the IPI. I am hoping to avoid a lock around that operation by
making a per-IPI-destination-CPU structure with lock, address, and ack
fields. Comments?
It seems Linux-PPC does a similar thing, I'd be happy with borrowing
that code:
arch/powerpc/kernel/smp.c global 214 int smp_call_function ()
I will always encourage, coming up with something better but lets
nail it first.
[snip]
diff -r 3dfeb3e4a03f xen/arch/powerpc/mpic_init.c
--- a/xen/arch/powerpc/mpic_init.c Fri Oct 13 11:00:32 2006 -0400
+++ b/xen/arch/powerpc/mpic_init.c Mon Oct 23 15:32:55 2006 -0400
@@ -358,6 +358,43 @@ static struct hw_interrupt_type *share_m
#endif
+static inline struct mpic * mpic_from_ipi(unsigned int ipi)
+{
+ return container_of(irq_desc[ipi].handler, struct mpic, hc_ipi);
+}
+
+static unsigned int mpic_startup_ipi(unsigned int irq)
+{
+printk(%s\n, __func__);
+struct mpic *pic = mpic_from_ipi(irq);
+pic-hc_ipi.enable(irq);
+return 0;
+}
at least in our code now, mpic pointer is static to this whole file
so mpic_from_ipi() is unnecessary. We don't have any multi-mpic
machines yet and looking at upstream Linux, they have solved this
problem another way.
+
+int request_irq(unsigned int irq,
+ irqreturn_t (*handler)(int, void *, struct cpu_user_regs *),
+ unsigned long irqflags, const char * devname, void *dev_id)
+{
+int retval;
+struct irqaction *action;
+
+printk(%s: %d: %p: %s: %p\n, __func__, irq, handler,
devname, dev_id);
+
+action = xmalloc_bytes(sizeof(struct irqaction));
plan xmalloc() takes a type and does the sizeof() for you, so:
action = xmalloc(struct irqaction);
+if (!action)
+ BUG();
I know this is RFC, and you know I'm a bug fan of BUG(), but
eventually I'd expect:
BUG_ON(!action)
if (!action)
return -ENOMEM
+
+action-handler = (void (*)(int, void *, struct cpu_user_regs
*))handler;
can you cast this with a local variable and comment that Xen's irq
action is older than Linux's.
+action-name = devname;
+action-dev_id = dev_id;
+
+retval = setup_irq(irq, action);
+if (retval)
+ BUG();
As the BUG above:
BUG_ON(retval);
if (reval)
xfree(action);
+
+return retval;
+}
+
struct hw_interrupt_type *xen_mpic_init(struct hw_interrupt_type
*xen_irq)
{
unsigned int isu_size;
@@ -397,6 +434,11 @@ struct hw_interrupt_type *xen_mpic_init(
hit = share_mpic(mpic-hc_irq, xen_irq);
printk(%s: success\n, __func__);
+
+mpic-hc_ipi.ack = xen_irq-ack;
+mpic-hc_ipi.startup = mpic_startup_ipi;
+mpic_request_ipis();
+
return hit;
}
[snip]
diff -r 3dfeb3e4a03f xen/arch/powerpc/smp.c
--- a/xen/arch/powerpc/smp.cFri Oct 13 11:00:32 2006 -0400
+++ b/xen/arch/powerpc/smp.cMon Oct 23 23:15:45 2006 -0400
@@ -22,6 +22,8 @@
#include xen/smp.h
#include asm/flushtlb.h
#include asm/debugger.h
+#include asm/mpic.h
+#include asm/mach-default/irq_vectors.h
int smp_num_siblings = 1;
int smp_num_cpus = 1;
@@ -46,11 +48,30 @@ void __flush_tlb_mask(cpumask_t mask, un
unimplemented();
}
+static void send_IPI_mask(cpumask_t mask, int vector)
+{
+unsigned long cpus;
+
+switch(vector) {
+case CALL_FUNCTION_VECTOR:
+case EVENT_CHECK_VECTOR:
+case INVALIDATE_TLB_VECTOR:
I'm pretty sure we should not be supporting the INVALIDATE_TLB_VECTOR
vector and will probably just do a broadcast TLB instead, do I'd like
to see this BUG().
+ break;
+default:
+ BUG();
+}
+
+BUG_ON(sizeof(mask.bits) != sizeof(unsigned long));
+cpus = mask.bits[0];
+
+mpic_send_ipi(vector, cpus);
I'd like to keep all knowledge of mpic in external.c and mpic_init.c,
so let make a new function smp_send_ipi() in external.c and move the
bounds checking there, sinec mpic_send_ipi() takes an unsigned int
for cpus, you should make sure that the bounds check on that rather
than unsigned long.
+}
+
void smp_send_event_check_mask(cpumask_t mask)
{
cpu_clear(smp_processor_id(), mask);
if (!cpus_empty(mask))
-unimplemented();
+send_IPI_mask(mask, EVENT_CHECK_VECTOR);
}
@@ -78,3 +99,39 @@ int
[XenPPC] Re: [Xen-devel] Status of xvd and problems with sd.
Ewan, any thoughts on this issue? -JX On Oct 23, 2006, at 10:43 AM, Jimi Xenidis wrote: On PPC we have the following problem with xm-test: http://wiki.xensource.com/xenwiki/XenFaq#head- baa7000e8fc28fd168650114dd2741b7f21da8fa Where we are told: all you need to do is disable the entire scsi subsystem This is undesirable since our (the XenPPC Team) goal is to have one Linux image to run everywhere. We could switch over all the xm-tests to use xvd (Xen Virtual Block Device), but before we do that we'd like to know what the support for xvd is and what if any issues/opinion are there with doing this? -JX ___ Xen-devel mailing list [EMAIL PROTECTED] http://lists.xensource.com/xen-devel ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Status of xvd and problems with sd.
On PPC we have the following problem with xm-test: http://wiki.xensource.com/xenwiki/XenFaq#head- baa7000e8fc28fd168650114dd2741b7f21da8fa Where we are told: all you need to do is disable the entire scsi subsystem This is undesirable since our (the XenPPC Team) goal is to have one Linux image to run everywhere. We could switch over all the xm-tests to use xvd (Xen Virtual Block Device), but before we do that we'd like to know what the support for xvd is and what if any issues/opinion are there with doing this? -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] VIO Block and Xm-Test
On Oct 23, 2006, at 2:56 AM, Tony Breeds wrote: Hi all, I'm slowly working my way through a default run on xm-test on my JS20 trying to determine if the tests that fail represent real problems with xen on PPC, or if they're showing problems with the tests themselves. By correcting some of the create/* tests (patches posted to xen-devel) XenPPC now passes that whole group. In looking at the block-* tests, I see that the failures are due to the domU kernel including scsi support, which then causes a conflict on major number 8, resulting in a lot of failures in xm-test. hmm.. If I try to do this manually, I get: Registering block device major 8 register_blkdev: cannot get major 8 for sd xen_blk: can't get major 8 with name sd vbd vbd-2065: 19 xlvbd_add at /local/domain/0/backend/vbd/1/2065 The problem is described in: http://wiki.xensource.com/xenwiki/XenFaq#head- baa7000e8fc28fd168650114dd2741b7f21da8fa Where we are told: all you need to do is disable the entire scsi subsystem GTFOOH! (said in my best soprano) There has to be a better way! [snip] I'd like to know how everyone feels about creating a make xen_domu_config target which turns of the driver that aren't needed? I think it is unacceptable. Seriously, it is really important to XenPPC that the same kernel image work everywhere Or alternatively suggestions on how to keep a unified kernel image that works? One alternative is to use the ide devices $ xm block-attach 3 file:/root/disk2 hdb2 w Works just fine, for disks. There is also the xvd (Xen Virtual Block Device) which can be attached using xen major 20 $ xm block-attach 6 file:/root/disk2 xvda w Which translates into (202,0), which is lanana blessed: http://www.be.kernel.org/pub/linux/docs/lanana/device-list/ devices-2.6+.txt I had to: mknod /dev/xvda b 202 0 to be able to mount it. I do not know what the official/current Xen support for xvd, but it is a good question, I'll ask. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] dom0 memory size results
On Oct 19, 2006, at 9:02 AM, Jimi Xenidis wrote: On Oct 19, 2006, at 2:30 AM, Amos Waterland wrote: On a JS21 with 8GB of RAM, we attempt 8 runs with the following dom0 memory requests: 128M 192M 256M 512M 700M 1G 2G 7G. Ok, we know that 2G of dom0 is not currently supported with the way we track memory today, described in: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=785 I'm surprised we need as much as 256M just to load dom0, but happy that 2G works now. I'm surprised that any amount from 64M to 2G (currently forced in 16M increments) does not allow for Dom0 to successfully make it thru init. If fact, the maples (which only have 512M) give 192M to dom0 by default. These are OOM issues with the kernel? If you cap Linux (without Xen) to these memory limits does Linux succeed? lets pick on 192, can you post a complete log? *sigh* it occurs to me that now that VIO is turned on we basically have allocated a struct page for every page on the machine in addition to the normal pages that dom0 will use, this would indeed have an impact on how much memory Dom0 has. -JX ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
