Re: [XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctlconversion for 64-b

2007-07-09 Thread Jan Beulich
Which structures do you think need further conversion? We've already fixed all the shared structures (e.g. sysctl) to use explicitly-sized types, so the PowerPC port has always had proper interfaces. For example, look at the definition of xen_ulong_t on the different architectures. The x86

Re: [XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctlconversion for 64-b

2007-07-09 Thread Keir Fraser
On 9/7/07 10:03, Jan Beulich [EMAIL PROTECTED] wrote: We've already fixed all the shared structures (e.g. sysctl) to use explicitly-sized types, so the PowerPC port has always had proper interfaces. For example, look at the definition of xen_ulong_t on the different architectures. The x86

[XenPPC] 64bit apps in DomU should get a more useful error message

2007-07-09 Thread Christian Ehrhardt
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 As far as I remember

[XenPPC] [PATCH] Take a writer lock for mmap_sem.

2007-07-09 Thread Hollis Blanchard
On Sat, 2007-07-07 at 10:20 +0100, Keir Fraser wrote: Changes inside powerpc files are fine. Obviously powerpc-specific changes inside common files are usually fine. Changes to locking protocols in common files (e.g., changed usage of mmap_sem in privcmd.c) is *not* fine. Please post patches

[XenPPC] Re: [Xen-devel] [PATCH] Take a writer lock for mmap_sem.

2007-07-09 Thread Keir Fraser
On 9/7/07 16:45, Hollis Blanchard [EMAIL PROTECTED] wrote: My mistake, I meant to send this separately. In 2.6.17, we did our own locking inside direct_remap_pfn_range(). In the current Linux tree though, the locking is done in privcmd_ioctl(). However, since direct_remap_pfn_range()

[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add #ifdef ARCH_HAS_DEV_MEM to archtecture specific file_operations.

2007-07-09 Thread Hollis Blanchard
On Sat, 2007-07-07 at 10:01 +0100, Keir Fraser wrote: By the way, I wonder how PPC manages to build both drivers/char/mem.c and drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be that mem_fops defined by the Xen file is picked up by the generic file. If

[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add #ifdef ARCH_HAS_DEV_MEM to archtecture specific file_operations.

2007-07-09 Thread Keir Fraser
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

[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add #ifdef ARCH_HAS_DEV_MEM to archtecture specific file_operations.

2007-07-09 Thread Hollis Blanchard
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

Re: [XenPPC] 64bit apps in DomU should get a more useful error message

2007-07-09 Thread Jimi Xenidis
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:

[XenPPC] todays xen-unstable is throwing gcc errors when compiling on PPC

2007-07-09 Thread Jerone Young
When compiling Xen on PPC today I get the following error that is being caused by casting (u32 *). Once the cast is removed all is well and things compile fine. Is this happening on x86 or x86-64 ? I'm using gcc 4.1.0 on Suse SLES 10. There Error: grant_table.c: In function

Re: [XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add #ifdef ARCH_HAS_DEV_MEM to archtecture specific file_operations.

2007-07-09 Thread Jimi Xenidis
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?

Re: [XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add #ifdef ARCH_HAS_DEV_MEM to archtecture specific file_operations.

2007-07-09 Thread Jimi Xenidis
On Jul 9, 2007, at 4:23 PM, Jimi Xenidis wrote: 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

[XenPPC] Re: [Xen-devel] todays xen-unstable is throwing gcc errors when compiling on PPC

2007-07-09 Thread Keir Fraser
This problem is caused by my patch which moved the addition of -fno-strict-aliasing to CFLAGS into Config.mk. At the same time I *removed* -fno-strict-aliasing from arch/{x86,powerpc,ia64}/Rules.mk. My assumption was that everyone would simply add to the CFLAGS created by Config.mk and

[XenPPC] [PATCH] Fix for PPC xen in xen-unstable .. missing header

2007-07-09 Thread Jerone Young
Fix build in xen-unstable for PPC. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff -r aa640601575f xen/arch/powerpc/sysctl.c --- a/xen/arch/powerpc/sysctl.c Mon Jul 09 14:51:44 2007 +0100 +++ b/xen/arch/powerpc/sysctl.c Mon Jul 09 17:12:59 2007 -0500 @@ -24,6 +24,7 @@ #include xen/sched.h