| Message ID | 1349796183-30648-1-git-send-email-arnd@arndb.de |
|---|---|
| State | New |
| Headers | show |
On Tue, 2012-10-09 at 16:22 +0100, Arnd Bergmann wrote: > * The XEN_BALLOON code requires the balloon infrastructure that is not > getting built on ARM. I've got patches to enable this, but not for 3.7 so this looks good for now. > * The tmem hypercall is not available on ARM > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the missing the end of this sentence? > * sys-hypervisor.c needs to include linux/err.h in order to use the > IS_ERR/PTR_ERR/ERR_PTR family of functions. I tripped over this too. Not sure where that patch got to though. > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ian Campbell <ian.campbell@citrix.com> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Cc: Jeremy Fitzhardinge <jeremy@goop.org> > Cc: xen-devel@lists.xensource.com > --- > arch/arm/Kconfig | 1 + > drivers/xen/Kconfig | 2 ++ > drivers/xen/sys-hypervisor.c | 1 + > 3 files changed, 4 insertions(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 6d2f7f5..85eaac3 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1846,6 +1846,7 @@ config XEN_DOM0 > config XEN > bool "Xen guest support on ARM (EXPERIMENTAL)" > depends on EXPERIMENTAL && ARM && OF > + depends on !CPU_V6 > help > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index d4dffcd..126d8ce 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -3,6 +3,7 @@ menu "Xen driver support" > > config XEN_BALLOON > bool "Xen memory balloon driver" > + depends on !ARM > default y > help > The balloon driver allows the Xen domain to request more memory from > @@ -145,6 +146,7 @@ config SWIOTLB_XEN > > config XEN_TMEM > bool > + depends on !ARM > default y if (CLEANCACHE || FRONTSWAP) > help > Shim to interface in-kernel Transcendent Memory hooks > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c > index 5e5ad7e..66a0a14 100644 > --- a/drivers/xen/sys-hypervisor.c > +++ b/drivers/xen/sys-hypervisor.c > @@ -11,6 +11,7 @@ > #include <linux/kernel.h> > #include <linux/module.h> > #include <linux/kobject.h> > +#include <linux/err.h> > > #include <asm/xen/hypervisor.h> > #include <asm/xen/hypercall.h>
Thanks for the patch and sorry for the build breakage! On Tue, 9 Oct 2012, Arnd Bergmann wrote: > * The XEN_BALLOON code requires the balloon infrastructure that is not > getting built on ARM. > > * The tmem hypercall is not available on ARM > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the > > * sys-hypervisor.c needs to include linux/err.h in order to use the > IS_ERR/PTR_ERR/ERR_PTR family of functions. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Cc: Jeremy Fitzhardinge <jeremy@goop.org> > Cc: xen-devel@lists.xensource.com > --- > arch/arm/Kconfig | 1 + > drivers/xen/Kconfig | 2 ++ > drivers/xen/sys-hypervisor.c | 1 + > 3 files changed, 4 insertions(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 6d2f7f5..85eaac3 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1846,6 +1846,7 @@ config XEN_DOM0 > config XEN > bool "Xen guest support on ARM (EXPERIMENTAL)" > depends on EXPERIMENTAL && ARM && OF > + depends on !CPU_V6 > help > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. Considering that we rely on the virtualization extensions, this one can be: depends on CPU_V7 The rest looks fine. I can submit a second patch to change !CPU_V6 into CPU_V7 later, if you prefer. > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig > index d4dffcd..126d8ce 100644 > --- a/drivers/xen/Kconfig > +++ b/drivers/xen/Kconfig > @@ -3,6 +3,7 @@ menu "Xen driver support" > > config XEN_BALLOON > bool "Xen memory balloon driver" > + depends on !ARM > default y > help > The balloon driver allows the Xen domain to request more memory from > @@ -145,6 +146,7 @@ config SWIOTLB_XEN > > config XEN_TMEM > bool > + depends on !ARM > default y if (CLEANCACHE || FRONTSWAP) > help > Shim to interface in-kernel Transcendent Memory hooks > > diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c > index 5e5ad7e..66a0a14 100644 > --- a/drivers/xen/sys-hypervisor.c > +++ b/drivers/xen/sys-hypervisor.c > @@ -11,6 +11,7 @@ > #include <linux/kernel.h> > #include <linux/module.h> > #include <linux/kobject.h> > +#include <linux/err.h> > > #include <asm/xen/hypervisor.h> > #include <asm/xen/hypercall.h> > -- > 1.7.10 >
On Tuesday 09 October 2012, Ian Campbell wrote: > > * The tmem hypercall is not available on ARM > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the > > missing the end of this sentence? Right, I meant to say * ARMv6 does not support cmpxchg on 16-bit words that are used in the Xen grant table code, so we must ensure that Xen support is only built on ARMv7-only kernels not combined ARMv6/v7 kernels. This should be fixed differently in the future. Arnd
On Tue, Oct 09, 2012 at 05:22:59PM +0200, Arnd Bergmann wrote: > * The XEN_BALLOON code requires the balloon infrastructure that is not > getting built on ARM. > > * The tmem hypercall is not available on ARM > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the "in the" what?
On Tue, Oct 09, 2012 at 04:40:54PM +0100, Jonathan Austin wrote: > Hi Arnd, > > On 09/10/12 16:22, Arnd Bergmann wrote: > > diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c > > index 9d0a300..0dc5385 100644 > > --- a/arch/arm/lib/delay.c > > +++ b/arch/arm/lib/delay.c > > @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val) > > *timer_val = delay_timer->read_current_timer(); > > return 0; > > } > > +EXPORT_SYMBOL_GPL(read_current_timer); > > > Perhaps this fits better in armksyms.c? That way it lives with > arm_delay_ops and friends. It's always much better to put things next to where they're defined rather than spreading them around. armksyms.c is a reminant of the 1.x days of doing things... but still remains to allow what are mostly assembly symbols to be exported.
On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote: > Here are some patches that belong into your domain, I hope you can > just send the lot to Linus the next time you send other patches. > > These bug fixes all address problems found with automated build testing. > Some of them have been around for a long time, other bugs are > regressions since the merge window. Apart from the sliced off comment in one commit (which XEN people need to confirm they're happy with the final version), I think these are otherwise fine... I'll hold off pulling them until that can be fixed. Thanks.
On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote: > On Tuesday 09 October 2012, Ian Campbell wrote: > > > * The tmem hypercall is not available on ARM > > > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the > > > > missing the end of this sentence? > > Right, I meant to say > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the > Xen grant table code, so we must ensure that Xen support is only built > on ARMv7-only kernels not combined ARMv6/v7 kernels. > > This should be fixed differently in the future. Is this is a build time failure because gcc/gas/etc refuses to generate these instructions if it is configured for v6? I ask because if it is only a runtime issue then we can reason that if we are running Xen specific grant table code, then we must be running on Xen and therefore must necessarily be running on a v7 (because Xen only support v7+virt extensions) even if the kernel happens to be capable of running on v6 too. Ian.
On Tue, 9 Oct 2012, Arnd Bergmann wrote: > The recently added Emma Mobile GPIO driver calls set_irq_flags > and irq_set_chip_and_handler for the interrupts it exports and > it can be built as a module, which currently fails with > > ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined! > > We either need to replace the call to set_irq_flags with something > else or export that function. This patch does the latter. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > Cc: Magnus Damm <damm@opensource.se> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Rafael J. Wysocki <rjw@sisk.pl> > Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by-me > Cc: Russell King <rmk+kernel@arm.linux.org.uk> > --- > arch/arm/kernel/irq.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c > index 16cedb4..8961650 100644 > --- a/arch/arm/kernel/irq.c > +++ b/arch/arm/kernel/irq.c > @@ -34,6 +34,7 @@ > #include <linux/list.h> > #include <linux/kallsyms.h> > #include <linux/proc_fs.h> > +#include <linux/export.h> > > #include <asm/exception.h> > #include <asm/mach/arch.h> > @@ -109,6 +110,7 @@ void set_irq_flags(unsigned int irq, unsigned int iflags) > /* Order is clear bits in "clr" then set bits in "set" */ > irq_modify_status(irq, clr, set & ~clr); > } > +EXPORT_SYMBOL_GPL(set_irq_flags); > > void __init init_IRQ(void) > { > -- > 1.7.10 > >
On Tue, 9 Oct 2012, Russell King - ARM Linux wrote: > On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote: > > Here are some patches that belong into your domain, I hope you can > > just send the lot to Linus the next time you send other patches. > > > > These bug fixes all address problems found with automated build testing. > > Some of them have been around for a long time, other bugs are > > regressions since the merge window. > > Apart from the sliced off comment in one commit (which XEN people need > to confirm they're happy with the final version), I think these are > otherwise fine... I'll hold off pulling them until that can be fixed. I am OK with the comment being truncated. I am going to submit a better fix for the Kconfig issues separately anyway, on top of this patch.
On Tue, Oct 09, 2012 at 05:23:00PM +0200, Arnd Bergmann wrote: > The Linaro cross toolchain and probably others nowadays default to > building in THUMB2 mode. When building a kernel for a CPU that does > not support THUMB2, the compiler complains about incorrect flags. > We can work around this by setting -marm for all non-T2 builds. > > Without this patch, building assabet_defconfig results in: > > usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] > arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] > firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default] > (and many more) > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > Acked-by: Nicolas Pitre <nico@linaro.org> > Cc: Russell King <rmk+kernel@arm.linux.org.uk> > Cc: Dave Martin <dave.martin@linaro.org> This looks like a sensible fix, but it could be worth amending the commit message to explain what was fixed, since it took me a moment or two to puzzle out why the code this patch removes was broken. Maybe something like: -marm was passed unconditionally for C files previously, but nothing was passed to the gcc frontend when processing .S files, resulting in a warning. The assembler never defaults to ARM unless -Wa,-mthumb is supplied explicitly, so the files were still assembled correctly. This patch makes sure that -marm is passed for .S files too, and also avoids the redundant gcc -marm -mthumb in Thumb kernels. Preferably with that (or equivalent): Acked-by: Dave Martin <dave.martin@linaro.org> > --- > arch/arm/Makefile | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index f023e3a..5f914fc 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -21,8 +21,6 @@ endif > OBJCOPYFLAGS :=-O binary -R .comment -S > GZFLAGS :=-9 > #KBUILD_CFLAGS +=-pipe > -# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb: > -KBUILD_CFLAGS +=$(call cc-option,-marm,) > > # Never generate .eh_frame > KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm) > @@ -105,17 +103,20 @@ endif > ifeq ($(CONFIG_THUMB2_KERNEL),y) > AFLAGS_AUTOIT :=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it) > AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W) > -CFLAGS_THUMB2 :=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN) > -AFLAGS_THUMB2 :=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb > +CFLAGS_ISA :=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN) > +AFLAGS_ISA :=$(CFLAGS_ISA) -Wa$(comma)-mthumb > # Work around buggy relocation from gas if requested: > ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y) > CFLAGS_MODULE +=-fno-optimize-sibling-calls > endif > +else > +CFLAGS_ISA :=$(call cc-option,-marm,) > +AFLAGS_ISA :=$(CFLAGS_ISA) > endif > > # Need -Uarm for gcc < 3.x > -KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_THUMB2) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm > -KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_THUMB2) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float > +KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm > +KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float > > CHECKFLAGS += -D__arm__ > > -- > 1.7.10 >
On Tuesday 09 October 2012, Ian Campbell wrote: > On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote: > > On Tuesday 09 October 2012, Ian Campbell wrote: > > > > * The tmem hypercall is not available on ARM > > > > > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the > > > > > > missing the end of this sentence? > > > > Right, I meant to say > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the > > Xen grant table code, so we must ensure that Xen support is only built > > on ARMv7-only kernels not combined ARMv6/v7 kernels. > > > > This should be fixed differently in the future. > > Is this is a build time failure because gcc/gas/etc refuses to generate > these instructions if it is configured for v6? > > I ask because if it is only a runtime issue then we can reason that if > we are running Xen specific grant table code, then we must be running on > Xen and therefore must necessarily be running on a v7 (because Xen only > support v7+virt extensions) even if the kernel happens to be capable of > running on v6 too. The underlying reason of course is that ARMv6 doesn't have those instructions. The symptom you see is a link error because gcc emits a reference to the (intentionally missing) __bad_cmpxchg() function from static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size) { unsigned long oldval, res; switch (size) { #ifndef CONFIG_CPU_V6 /* min ARCH >= ARMv6K */ case 1: ... break; case 2: ... break; #endif case 4: ... break; default: __bad_cmpxchg(ptr, size); oldval = 0; } return oldval; } The possible solutions I can see for this are: * change the grant table format to use 32 bits for the flags on ARM * change the code to always cmpxchg the entire 32 bit word including the flags. * implement your own cmpxchg wrapper that may be implemented using a spinlock rather than cmpxchg if ARMv6 is enabled. Arnd
On Tuesday 09 October 2012, Stefano Stabellini wrote: > > config XEN > > bool "Xen guest support on ARM (EXPERIMENTAL)" > > depends on EXPERIMENTAL && ARM && OF > > + depends on !CPU_V6 > > help > > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > Considering that we rely on the virtualization extensions, this one can > be: > > depends on CPU_V7 > > The rest looks fine. I can submit a second patch to change !CPU_V6 into > CPU_V7 later, if you prefer. CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a combined kernel for both V6 and V7. The code also needs to depend on ARMv7 with virtualization extensions, but that is a different issue. We don't actually have a configuration symbol for that yet, as far as I can tell. Arnd
On Tue, Oct 9, 2012 at 5:22 PM, Arnd Bergmann <arnd@arndb.de> wrote: > The recently added Emma Mobile GPIO driver calls set_irq_flags > and irq_set_chip_and_handler for the interrupts it exports and > it can be built as a module, which currently fails with > > ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined! > > We either need to replace the call to set_irq_flags with something > else or export that function. This patch does the latter. Argh! And I cannot think of anything more elegant so Acked-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote: > On Tuesday 09 October 2012, Stefano Stabellini wrote: > > > config XEN > > > bool "Xen guest support on ARM (EXPERIMENTAL)" > > > depends on EXPERIMENTAL && ARM && OF > > > + depends on !CPU_V6 > > > help > > > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > > > Considering that we rely on the virtualization extensions, this one can > > be: > > > > depends on CPU_V7 > > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into > > CPU_V7 later, if you prefer. > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a > combined kernel for both V6 and V7. The code also needs to depend on ARMv7 > with virtualization extensions, but that is a different issue. We don't > actually have a configuration symbol for that yet, as far as I can tell. I don't think the guest kernels (including dom0) need the extensions to run under Xen, they are only need by Xen itself. The guests should just see a relatively normal v7 processor. Stefano, does that sound right? Ian.
On Tue, 2012-10-09 at 19:19 +0100, Arnd Bergmann wrote: > On Tuesday 09 October 2012, Ian Campbell wrote: > > On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote: > > > On Tuesday 09 October 2012, Ian Campbell wrote: > > > > > * The tmem hypercall is not available on ARM > > > > > > > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the > > > > > > > > missing the end of this sentence? > > > > > > Right, I meant to say > > > > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the > > > Xen grant table code, so we must ensure that Xen support is only built > > > on ARMv7-only kernels not combined ARMv6/v7 kernels. > > > > > > This should be fixed differently in the future. > > > > Is this is a build time failure because gcc/gas/etc refuses to generate > > these instructions if it is configured for v6? > > > > I ask because if it is only a runtime issue then we can reason that if > > we are running Xen specific grant table code, then we must be running on > > Xen and therefore must necessarily be running on a v7 (because Xen only > > support v7+virt extensions) even if the kernel happens to be capable of > > running on v6 too. > > The underlying reason of course is that ARMv6 doesn't have those > instructions. The symptom you see is a link error because gcc emits > a reference to the (intentionally missing) __bad_cmpxchg() function > from OK, then your fix is the best one for now. > [...] > The possible solutions I can see for this are: > > * change the grant table format to use 32 bits for the flags on ARM > * change the code to always cmpxchg the entire 32 bit word including the flags. I'd need to check the grant table semantics to see if this will be possible. > * implement your own cmpxchg wrapper that may be implemented using a spinlock > rather than cmpxchg if ARMv6 is enabled. Even if ARMv6 is enabled the grant table code will never be running on one so so it might be ok to just have our own wrapper which unconditionally uses the v7 instruction? That might upset gas though. > > Arnd
On Wednesday 10 October 2012, Ian Campbell wrote: > > * implement your own cmpxchg wrapper that may be implemented using a spinlock > > rather than cmpxchg if ARMv6 is enabled. > > Even if ARMv6 is enabled the grant table code will never be running on > one so so it might be ok to just have our own wrapper which > unconditionally uses the v7 instruction? That might upset gas though. Yes, that would be possible. You can tell gas to ignore the instruction set in this case. If you do this, you can implement the update functions more efficiently using direct ldrexh/strexh in assembler to avoid doing two nested loops. I assume that you don't need the v1 grant table code on ARM anyway, so the only code you need to look at is while (!((flags = *pflags) & GTF_transfer_committed)) { if (sync_cmpxchg(pflags, flags, 0) == flags) return 0; cpu_relax(); } which should transform nicely into a few lines of inline assembly. Arnd
On Wed, 10 Oct 2012, Ian Campbell wrote: > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote: > > On Tuesday 09 October 2012, Stefano Stabellini wrote: > > > > config XEN > > > > bool "Xen guest support on ARM (EXPERIMENTAL)" > > > > depends on EXPERIMENTAL && ARM && OF > > > > + depends on !CPU_V6 > > > > help > > > > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > > > > > Considering that we rely on the virtualization extensions, this one can > > > be: > > > > > > depends on CPU_V7 > > > > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into > > > CPU_V7 later, if you prefer. > > > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7 > > with virtualization extensions, but that is a different issue. We don't > > actually have a configuration symbol for that yet, as far as I can tell. > > I don't think the guest kernels (including dom0) need the extensions to > run under Xen, they are only need by Xen itself. The guests should just > see a relatively normal v7 processor. > > Stefano, does that sound right? Keep in mind that we are using HVC to issue hypercalls, and HVC has been introduced with the virtualization extensions, if I am not mistaken.
On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote: > On Wed, 10 Oct 2012, Ian Campbell wrote: > > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote: > > > On Tuesday 09 October 2012, Stefano Stabellini wrote: > > > > > config XEN > > > > > bool "Xen guest support on ARM (EXPERIMENTAL)" > > > > > depends on EXPERIMENTAL && ARM && OF > > > > > + depends on !CPU_V6 > > > > > help > > > > > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > > > > > > > Considering that we rely on the virtualization extensions, this one can > > > > be: > > > > > > > > depends on CPU_V7 > > > > > > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into > > > > CPU_V7 later, if you prefer. > > > > > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a > > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7 > > > with virtualization extensions, but that is a different issue. We don't > > > actually have a configuration symbol for that yet, as far as I can tell. > > > > I don't think the guest kernels (including dom0) need the extensions to > > run under Xen, they are only need by Xen itself. The guests should just > > see a relatively normal v7 processor. > > > > Stefano, does that sound right? > > Keep in mind that we are using HVC to issue hypercalls, and HVC has been > introduced with the virtualization extensions, if I am not mistaken. I think we can ignore that in this context since it is only used by bits which are already virtualisation aware -- i.e. you wouldn't want to add it to the Kconfig as a dependency for Xen. Ian.
On Wed, 10 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-10 at 15:47 +0100, Stefano Stabellini wrote: > > On Wed, 10 Oct 2012, Ian Campbell wrote: > > > On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote: > > > > On Tuesday 09 October 2012, Stefano Stabellini wrote: > > > > > > config XEN > > > > > > bool "Xen guest support on ARM (EXPERIMENTAL)" > > > > > > depends on EXPERIMENTAL && ARM && OF > > > > > > + depends on !CPU_V6 > > > > > > help > > > > > > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. > > > > > > > > > > Considering that we rely on the virtualization extensions, this one can > > > > > be: > > > > > > > > > > depends on CPU_V7 > > > > > > > > > > The rest looks fine. I can submit a second patch to change !CPU_V6 into > > > > > CPU_V7 later, if you prefer. > > > > > > > > CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a > > > > combined kernel for both V6 and V7. The code also needs to depend on ARMv7 > > > > with virtualization extensions, but that is a different issue. We don't > > > > actually have a configuration symbol for that yet, as far as I can tell. > > > > > > I don't think the guest kernels (including dom0) need the extensions to > > > run under Xen, they are only need by Xen itself. The guests should just > > > see a relatively normal v7 processor. > > > > > > Stefano, does that sound right? > > > > Keep in mind that we are using HVC to issue hypercalls, and HVC has been > > introduced with the virtualization extensions, if I am not mistaken. > > I think we can ignore that in this context since it is only used by bits > which are already virtualisation aware -- i.e. you wouldn't want to add > it to the Kconfig as a dependency for Xen. Considering that ARM CPU_V* symbols are not mutually exclusive, if Linux had a CPU_V7_VIRTEXT symbol I don't see why we shouldn't add it to our list of dependencies. It is more accurate than CPU_V7 after all. But I don't think that it is necessary to introduce one now only for Xen, because like you said, we only need HVC and that is only used in virtualization aware code.
Am 09.10.2012 18:06, schrieb Russell King - ARM Linux: > On Tue, Oct 09, 2012 at 04:40:54PM +0100, Jonathan Austin wrote: >> Hi Arnd, >> >> On 09/10/12 16:22, Arnd Bergmann wrote: >>> diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c >>> index 9d0a300..0dc5385 100644 >>> --- a/arch/arm/lib/delay.c >>> +++ b/arch/arm/lib/delay.c >>> @@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val) >>> *timer_val = delay_timer->read_current_timer(); >>> return 0; >>> } >>> +EXPORT_SYMBOL_GPL(read_current_timer); >> >> >> Perhaps this fits better in armksyms.c? That way it lives with >> arm_delay_ops and friends. > > It's always much better to put things next to where they're defined > rather than spreading them around. > > armksyms.c is a reminant of the 1.x days of doing things... but still > remains to allow what are mostly assembly symbols to be exported. I needed that to build udlfb as a module. For the 3.6 stable kernels this has to be done in arch/arm/kernel/arch_timer.c (along with an #include <linux/export.h>) So I'm not sure if an Cc: <stable@vger.kernel.org> can be used here, but a patch should be submitted for inclusion into the 3.6 stable series too. Regards, Alexander
From: <arnd@arndb.de> Hi Russell, Here are some patches that belong into your domain, I hope you can just send the lot to Linus the next time you send other patches. These bug fixes all address problems found with automated build testing. Some of them have been around for a long time, other bugs are regressions since the merge window. Arnd The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659: Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk for you to fetch changes up to 93c6cee8e966ceb78a08e6a69a3afc948b74d254: ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 17:07:44 +0200) ---------------------------------------------------------------- Arnd Bergmann (9): ARM: kprobes: make more tests conditional ARM: export set_irq_flags ARM: Fix another build warning in arch/arm/mm/alignment.c ARM: export default read_current_timer ARM: Xen: fix initial build problems: ARM: pass -marm to gcc by default for both C and assembler ARM: be really quiet when building with 'make -s' ARM: binfmt_flat: unused variable 'persistent' ARM: warnings in arch/arm/include/asm/uaccess.h arch/arm/Kconfig | 1 + arch/arm/Makefile | 13 +++++++------ arch/arm/boot/Makefile | 10 +++++----- arch/arm/include/asm/flat.h | 2 +- arch/arm/include/asm/uaccess.h | 4 ++-- arch/arm/kernel/irq.c | 2 ++ arch/arm/kernel/kprobes-test-arm.c | 4 ++++ arch/arm/lib/delay.c | 1 + arch/arm/mm/alignment.c | 4 +++- arch/arm/tools/Makefile | 2 +- drivers/xen/Kconfig | 2 ++ drivers/xen/sys-hypervisor.c | 1 + 12 files changed, 30 insertions(+), 16 deletions(-) Cc: bryan.wu@canonical.com Cc: catalin.marinas@arm.com Cc: dave.martin@linaro.org Cc: jeremy@goop.org Cc: jonathan.austin@arm.com Cc: konrad.wilk@oracle.com Cc: leif.lindholm@arm.com Cc: linus.walleij@linaro.org Cc: damm@opensource.se Cc: mmarek@suse.cz Cc: rjw@sisk.pl Cc: rmk+kernel@arm.linux.org.uk Cc: stefano.stabellini@eu.citrix.com Cc: sboyd@codeaurora.org Cc: tglx@linutronix.de Cc: will.deacon@arm.com Cc: xen-devel@lists.xensource.com