[XenPPC] [PATCH] Fix for PPC xen in xen-unstable .. missing header
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 #include #include +#include #include #include #include ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] todays xen-unstable is throwing gcc errors when compiling on PPC
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
xen/Rules.mk, just to add arch-specific extras.
I see you do not do this because you have a 'CFLAGS :=' in your
arch/powerpc/Rules.mk. So you need to do one of:
1. Get rid of the 'CFLAGS :=' and simply adapt the generic CFLAGS.
2. Add CFLAGS += -fno-strict-aliasing back into your Rules.mk.
Unless there is a good reason to do otherwise, (1) is the way to go.
-- Keir
On 9/7/07 21:11, "Jerone Young" <[EMAIL PROTECTED]> wrote:
> 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 gnttab_prepare_for_transfer¹:
> grant_table.c:825: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> grant_table.c: In function __acquire_grant_for_copy¹:
> grant_table.c:1055: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> grant_table.c:1080: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> grant_table.c:1080: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> grant_table.c:1080: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> grant_table.c:1080: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> grant_table.c:1080: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> make[3]: *** [grant_table.o] Error 1
> make[3]: Leaving directory `/Work/xen-unstable.hg/xen/common'
> make[2]: *** [/Work/xen-unstable.hg/xen/common/built_in.o] Error 2
> make[2]: Leaving directory `/Work/xen-unstable.hg/xen/arch/powerpc'
> make[1]: *** [/Work/xen-unstable.hg/xen/xen] Error 2
> make[1]: Leaving directory `/Work/xen-unstable.hg/xen'
> make: *** [build] Error 2
>
>
>
> ___
> 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] 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 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 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. s/CONFIG_XEN_DEVMEM/CONFIG_XEN_DEVMEM=n/ -JX ___ 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] 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
[XenPPC] todays xen-unstable is throwing gcc errors when compiling on PPC
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 ‘gnttab_prepare_for_transfer’: grant_table.c:825: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c: In function ‘__acquire_grant_for_copy’: grant_table.c:1055: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c:1080: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c:1080: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c:1080: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c:1080: warning: dereferencing type-punned pointer will break strict-aliasing rules grant_table.c:1080: warning: dereferencing type-punned pointer will break strict-aliasing rules make[3]: *** [grant_table.o] Error 1 make[3]: Leaving directory `/Work/xen-unstable.hg/xen/common' make[2]: *** [/Work/xen-unstable.hg/xen/common/built_in.o] Error 2 make[2]: Leaving directory `/Work/xen-unstable.hg/xen/arch/powerpc' make[1]: *** [/Work/xen-unstable.hg/xen/xen] Error 2 make[1]: Leaving directory `/Work/xen-unstable.hg/xen' make: *** [build] Error 2 ___ 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
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
[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.
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... :) > > If you don't need to build both then there is potentially no problem with > the Xen file hijacking the xlate_dev_mem() functions. PowerPC Linux builds support for multiple platforms, including multiple hypervisors, into a single binary (paravirt_ops was inspired by ppc_md). For the most part our Xen patches continue this model, but because we don't really test our Xen kernel on non-Xen platforms, there are a couple bugs that would need fixing. So compile-time ifdefs for /dev/mem won't work long-term, but I'm not really worried about it. -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.
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... :) If you don't need to build both then there is potentially no problem with the Xen file hijacking the xlate_dev_mem() functions. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.
On Sat, 2007-07-07 at 10:01 +0100, Keir Fraser wrote: > > By the way, I wonder how PPC manages to build both drivers/char/mem.c and > drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be > that mem_fops defined by the Xen file is picked up by the generic file. If > !ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up the Xen > mem_fops? Hmmm, yeah. Looks like we haven't tested that... :) -- Hollis Blanchard IBM Linux Technology Center ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] Re: [Xen-devel] [PATCH] Take a writer lock for mmap_sem.
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() is modifying the mm_struct, > shouldn't that be a a write lock rather than a read lock? Ah yes, agreed. All other callers seem to get this implicitly because they are ->mmap handlers. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
[XenPPC] [PATCH] Take a writer lock for mmap_sem.
On Sat, 2007-07-07 at 10:20 +0100, Keir Fraser wrote:
> Changes inside powerpc files are fine. Obviously powerpc-specific changes
> inside common files are usually fine. Changes to locking protocols in common
> files (e.g., changed usage of mmap_sem in privcmd.c) is *not* fine. Please
> post patches for that kind of thing.
My mistake, I meant to send this separately.
In 2.6.17, we did our own locking inside direct_remap_pfn_range(). In
the current Linux tree though, the locking is done in privcmd_ioctl().
However, since direct_remap_pfn_range() is modifying the mm_struct,
shouldn't that be a a write lock rather than a read lock?
[XEN][LINUX] Take a writer lock for mmap_sem.
direct_remap_pfn_range() will be modifying the mm.
Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
diff -r e5f633c33025 drivers/xen/privcmd/privcmd.c
--- a/drivers/xen/privcmd/privcmd.c Fri Jul 06 17:35:53 2007 +0100
+++ b/drivers/xen/privcmd/privcmd.c Mon Jul 09 10:07:32 2007 -0500
@@ -111,7 +112,7 @@ static int privcmd_ioctl(struct inode *i
if (copy_from_user(&msg, p, sizeof(msg)))
return -EFAULT;
- down_read(&mm->mmap_sem);
+ down_write(&mm->mmap_sem);
vma = find_vma(mm, msg.va);
rc = -EINVAL;
@@ -153,7 +154,7 @@ static int privcmd_ioctl(struct inode *i
rc = 0;
mmap_out:
- up_read(&mm->mmap_sem);
+ up_write(&mm->mmap_sem);
ret = rc;
}
break;
@@ -176,14 +177,14 @@ static int privcmd_ioctl(struct inode *i
if ((m.num <= 0) || (nr_pages > (LONG_MAX >> PAGE_SHIFT)))
return -EINVAL;
- down_read(&mm->mmap_sem);
+ down_write(&mm->mmap_sem);
vma = find_vma(mm, m.addr);
if (!vma ||
(m.addr != vma->vm_start) ||
((m.addr + (nr_pages << PAGE_SHIFT)) != vma->vm_end) ||
!privcmd_enforce_singleshot_mapping(vma)) {
- up_read(&mm->mmap_sem);
+ up_write(&mm->mmap_sem);
return -EINVAL;
}
@@ -191,7 +192,7 @@ static int privcmd_ioctl(struct inode *i
addr = m.addr;
for (i = 0; i < nr_pages; i++, addr += PAGE_SIZE, p++) {
if (get_user(mfn, p)) {
- up_read(&mm->mmap_sem);
+ up_write(&mm->mmap_sem);
return -EFAULT;
}
@@ -202,7 +203,7 @@ static int privcmd_ioctl(struct inode *i
put_user(0xF000 | mfn, p);
}
- up_read(&mm->mmap_sem);
+ up_write(&mm->mmap_sem);
ret = 0;
}
break;
--
Hollis Blanchard
IBM Linux Technology Center
___
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
[XenPPC] 64bit apps in DomU should get a more useful error message
Example:
#include
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 DomU systems are 32bit (please correct me if
not) even if our kernel may say otherwise:
uname -a
Linux linux 2.6.18-Xen #25 SMP Sun Jul 29 00:29:02 CEST 2007 ppc64 ppc64
ppc64 GNU/Linux
I played a bit around with powerpc32 which changes the env so that e.g.
uname -m will report a 32bit system, but this did neither help me to get
64bit apps running (expected) nor better error messages.
The problem is not that 64bit apps do not run, but I think the message
should be something better than "No such file or directory"
->My question now: could/should we add a more sophisticated mechanism to
give the user running into this something like "you are not 64bit" ?
--
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
Re: [XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctlconversion for 64-b
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 interfaces were frozen too early, >> cementing this problem for you. > > Oh, sorry, I forgot that you had this taken care of implicitly on PPC. > I had hoped we could leverage the code you are adding for x86, but - > no luck. I think the only structure that actually needs conversion is the xen_pfn_t array in privcmd_mmapbatch. So it's not as bad as it first appears. -- Keir ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
Re: [XenPPC] Re: [Xen-devel] [PATCH 6 of 6] [XEN][LINUX] Add 32-bit privcmd ioctlconversion for 64-b
>Which structures do you think need further conversion? > >We've already fixed all the shared structures (e.g. sysctl) to use >explicitly-sized types, so the PowerPC port has always had proper >interfaces. For example, look at the definition of xen_ulong_t on the >different architectures. The x86 interfaces were frozen too early, >cementing this problem for you. Oh, sorry, I forgot that you had this taken care of implicitly on PPC. I had hoped we could leverage the code you are adding for x86, but - no luck. Jan ___ Xen-ppc-devel mailing list Xen-ppc-devel@lists.xensource.com http://lists.xensource.com/xen-ppc-devel
