* [BUG] x86 kenel won't boot under Virtual PC
@ 2008-08-31 18:22 David Sanders
2008-08-31 18:47 ` Linus Torvalds
[not found] ` <48C1C156.9080003@zytor.com>
0 siblings, 2 replies; 61+ messages in thread
From: David Sanders @ 2008-08-31 18:22 UTC (permalink / raw)
To: linux-kernel
Cc: Linus Torvalds, Jan Beulich, Andi Kleen, Ingo Molnar, Thomas Gleixner
I recently discovered that x86 kernels won't boot under Virtual PC. In this
case paravirt was not built into the kernel. The kernel just "hangs" on
attempted boot with no error messages. Git-bisect pinpointed the following
commit as the problem:
commit 32c464f5d9701db45bc1673288594e664065388e
Author: Jan Beulich <jbeulich@novell.com>
Date: Wed Oct 17 18:04:41 2007 +0200
x86: multi-byte single instruction NOPs
Add support for and use the multi-byte NOPs recently documented to be
available on all PentiumPro and later processors.
This patch only applies cleanly on top of the "x86: misc.
constifications" patch sent earlier.
[ tglx: arch/x86 adaptation ]
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
arch/x86/kernel/alternative.c | 23 ++++++++++++++++++++++-
include/asm-x86/processor_32.h | 22 ++++++++++++++++++++++
include/asm-x86/processor_64.h | 22 ++++++++++++++++++++++
3 files changed, 66 insertions(+), 1 deletion(-)
:040000 040000 9226efb160ea180e8c419134b82e0a6938868c1a
12daabe81d9cda0d574815c0957a24c1028c8fb0 M arch
:040000 040000 7ab3918741abcb203bd25289d2c6e789bed64fc1
eb662fea6ed7904074c87dd004b9f6d23964c844 M include
Any suggestion on where to go from here would be appreciated.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-08-31 18:22 [BUG] x86 kenel won't boot under Virtual PC David Sanders
@ 2008-08-31 18:47 ` Linus Torvalds
2008-08-31 19:27 ` Arjan van de Ven
2008-08-31 20:03 ` David Sanders
[not found] ` <48C1C156.9080003@zytor.com>
1 sibling, 2 replies; 61+ messages in thread
From: Linus Torvalds @ 2008-08-31 18:47 UTC (permalink / raw)
To: David Sanders
Cc: linux-kernel, Jan Beulich, Andi Kleen, Ingo Molnar, Thomas Gleixner
On Sun, 31 Aug 2008, David Sanders wrote:
>
> I recently discovered that x86 kernels won't boot under Virtual PC.
What CPU does Virtual PC emulate? As far as Wikipedia is concerned (not
that I'd take it on complete faith) it emulates a 32-bit Intel Pentium II.
And that commit makes the kernel use the "P6 nops" for such hardware.
Maybe Virtual PC doesn't support the newer intel nop things?
Intel docs say that it should be available on any intel CPU that has
CPUID.01H.EAX[11:8] = 0110B or 1111B. That's the "family ID", and Pentium
II should have a family ID of 6 (ie that 0110B case).
So it sounds like a Virtual PC bug, but I dunno. And maybe we should just
use the legcay nops for anything that isn't modern (ie P4+ or Core)?
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-08-31 18:47 ` Linus Torvalds
@ 2008-08-31 19:27 ` Arjan van de Ven
2008-08-31 19:39 ` Linus Torvalds
2008-08-31 20:03 ` David Sanders
1 sibling, 1 reply; 61+ messages in thread
From: Arjan van de Ven @ 2008-08-31 19:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Sanders, linux-kernel, Jan Beulich, Andi Kleen,
Ingo Molnar, Thomas Gleixner
On Sun, 31 Aug 2008 11:47:04 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Sun, 31 Aug 2008, David Sanders wrote:
> >
> > I recently discovered that x86 kernels won't boot under Virtual PC.
>
> What CPU does Virtual PC emulate? As far as Wikipedia is concerned
> (not that I'd take it on complete faith) it emulates a 32-bit Intel
> Pentium II.
>
> And that commit makes the kernel use the "P6 nops" for such hardware.
> Maybe Virtual PC doesn't support the newer intel nop things?
>
> Intel docs say that it should be available on any intel CPU that has
> CPUID.01H.EAX[11:8] = 0110B or 1111B. That's the "family ID", and
> Pentium II should have a family ID of 6 (ie that 0110B case).
>
> So it sounds like a Virtual PC bug, but I dunno. And maybe we should
> just use the legcay nops for anything that isn't modern (ie P4+ or
> Core)?
it's probably even a security bug in that I don't see what would be
stopping a ring 3 user process from executing these instructions...
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-08-31 19:27 ` Arjan van de Ven
@ 2008-08-31 19:39 ` Linus Torvalds
2008-09-05 15:38 ` David Sanders
0 siblings, 1 reply; 61+ messages in thread
From: Linus Torvalds @ 2008-08-31 19:39 UTC (permalink / raw)
To: Arjan van de Ven
Cc: David Sanders, linux-kernel, Jan Beulich, Andi Kleen,
Ingo Molnar, Thomas Gleixner
On Sun, 31 Aug 2008, Arjan van de Ven wrote:
>
> it's probably even a security bug in that I don't see what would be
> stopping a ring 3 user process from executing these instructions...
Well, it could be that Virtual PC raises a #UD exception in the virtual
machine. In user space, that would just cause the kernel to kill the poor
innocent victim. But when the kernel gets a #UD exception on what it
expects to be a nop, it just won't work.
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-08-31 18:47 ` Linus Torvalds
2008-08-31 19:27 ` Arjan van de Ven
@ 2008-08-31 20:03 ` David Sanders
2008-09-01 20:23 ` David Sanders
1 sibling, 1 reply; 61+ messages in thread
From: David Sanders @ 2008-08-31 20:03 UTC (permalink / raw)
To: linux-kernel
Cc: Linus Torvalds, Jan Beulich, Andi Kleen, Ingo Molnar, Thomas Gleixner
On Sunday 31 August 2008 14:47, Linus Torvalds wrote:
> On Sun, 31 Aug 2008, David Sanders wrote:
> > I recently discovered that x86 kernels won't boot under Virtual PC.
>
> What CPU does Virtual PC emulate? As far as Wikipedia is concerned (not
> that I'd take it on complete faith) it emulates a 32-bit Intel Pentium II.
>
> And that commit makes the kernel use the "P6 nops" for such hardware.
> Maybe Virtual PC doesn't support the newer intel nop things?
>
> Intel docs say that it should be available on any intel CPU that has
> CPUID.01H.EAX[11:8] = 0110B or 1111B. That's the "family ID", and Pentium
> II should have a family ID of 6 (ie that 0110B case).
>
> So it sounds like a Virtual PC bug, but I dunno. And maybe we should just
> use the legcay nops for anything that isn't modern (ie P4+ or Core)?
>
> Linus
Virtual PC does not emulate a processor like it does with the motherboard,
video, NIC ,etc. What you see in the virtual machine is the actual
processor, except that Virtual PC looks at all of your instructions and
modifies ring 0 code and the like. It may be that Virtual PC was not
designed with an awareness of these nops that the commit added.
I would suggest an configuration option to select legacy-nops or newer-nops
and a kernel boot-time parameter so it can be disabled to allow installation
of a distribution for example.
I would be happy to submit such a patch if you agree (or I'll try to anyway).
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-08-31 20:03 ` David Sanders
@ 2008-09-01 20:23 ` David Sanders
2008-09-01 22:22 ` Linus Torvalds
0 siblings, 1 reply; 61+ messages in thread
From: David Sanders @ 2008-09-01 20:23 UTC (permalink / raw)
To: linux-kernel
Cc: Linus Torvalds, Jan Beulich, Ingo Molnar, Thomas Gleixner, Andi Kleen
On Sunday 31 August 2008 16:03, David Sanders wrote:
> On Sunday 31 August 2008 14:47, Linus Torvalds wrote:
> > On Sun, 31 Aug 2008, David Sanders wrote:
> > > I recently discovered that x86 kernels won't boot under Virtual PC.
> >
> > What CPU does Virtual PC emulate? As far as Wikipedia is concerned (not
> > that I'd take it on complete faith) it emulates a 32-bit Intel Pentium
> > II.
> >
> > And that commit makes the kernel use the "P6 nops" for such hardware.
> > Maybe Virtual PC doesn't support the newer intel nop things?
> >
> > Intel docs say that it should be available on any intel CPU that has
> > CPUID.01H.EAX[11:8] = 0110B or 1111B. That's the "family ID", and Pentium
> > II should have a family ID of 6 (ie that 0110B case).
> >
> > So it sounds like a Virtual PC bug, but I dunno. And maybe we should just
> > use the legcay nops for anything that isn't modern (ie P4+ or Core)?
> >
> > Linus
>
> Virtual PC does not emulate a processor like it does with the motherboard,
> video, NIC ,etc. What you see in the virtual machine is the actual
> processor, except that Virtual PC looks at all of your instructions and
> modifies ring 0 code and the like. It may be that Virtual PC was not
> designed with an awareness of these nops that the commit added.
>
> I would suggest an configuration option to select legacy-nops or newer-nops
> and a kernel boot-time parameter so it can be disabled to allow
> installation of a distribution for example.
>
> I would be happy to submit such a patch if you agree (or I'll try to
> anyway).
OK, below is my patch. The problem is I just built with it and the boot
problem still exists. Either the patch is flawed or git-bisect gave me the
wrong commit. Any help would be appreciated.
David
Signed-off-by: David Sanders <linux@sandersweb.net>
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ed92864..a38f362 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -445,6 +445,13 @@ config PARAVIRT_DEBUG
Enable to debug paravirt_ops internals. Specifically, BUG if
a paravirt_op is missing when it is called.
+config INTEL_NOPS
+ bool "Use legacy x86 NOPS"
+ depends on X86_32
+ help
+ This option tells kernel to use legacy x86 nops
+
+
config MEMTEST
bool "Memtest"
help
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 2763cb3..10713e4 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -58,6 +58,16 @@ static int __init setup_noreplace_paravirt(char *str)
__setup("noreplace-paravirt", setup_noreplace_paravirt);
#endif
+static int intel_legacy_nops = 0;
+
+static int __init setup_intel_legacy_nops(char *str)
+{
+ intel_legacy_nops = 1;
+ return 1;
+}
+
+__setup("intel-legacy-nops", setup_intel_legacy_nops);
+
#define DPRINTK(fmt, args...) if (debug_alternative) \
printk(KERN_DEBUG fmt, args)
@@ -167,12 +177,17 @@ const unsigned char *const *find_nop_table(void)
const unsigned char *const *noptable = intel_nops;
int i;
- for (i = 0; noptypes[i].cpuid >= 0; i++) {
- if (boot_cpu_has(noptypes[i].cpuid)) {
- noptable = noptypes[i].noptable;
- break;
+ if (!intel_legacy_nops) {
+#ifndef CONFIG_INTEL_NOPS
+ for (i = 0; noptypes[i].cpuid >= 0; i++) {
+ if (boot_cpu_has(noptypes[i].cpuid)) {
+ noptable = noptypes[i].noptable;
+ break;
+ }
}
+#endif /* CONFIG_INTEL_NOPS */
}
+
return noptable;
}
^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-01 20:23 ` David Sanders
@ 2008-09-01 22:22 ` Linus Torvalds
2008-09-02 12:08 ` David Sanders
0 siblings, 1 reply; 61+ messages in thread
From: Linus Torvalds @ 2008-09-01 22:22 UTC (permalink / raw)
To: David Sanders
Cc: linux-kernel, Jan Beulich, Ingo Molnar, Thomas Gleixner, Andi Kleen
On Mon, 1 Sep 2008, David Sanders wrote:
>
> OK, below is my patch. The problem is I just built with it and the boot
> problem still exists. Either the patch is flawed or git-bisect gave me the
> wrong commit. Any help would be appreciated.
Try just reverting the commit that you bisected to, and double-check. If
your bisect was flawed, there's no point even staring at the nop code ;)
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-01 22:22 ` Linus Torvalds
@ 2008-09-02 12:08 ` David Sanders
2008-09-02 18:12 ` Linus Torvalds
0 siblings, 1 reply; 61+ messages in thread
From: David Sanders @ 2008-09-02 12:08 UTC (permalink / raw)
To: linux-kernel
Cc: Linus Torvalds, Jan Beulich, Ingo Molnar, Thomas Gleixner, Andi Kleen
On Monday 01 September 2008 18:22, Linus Torvalds wrote:
> On Mon, 1 Sep 2008, David Sanders wrote:
> > OK, below is my patch. The problem is I just built with it and the boot
> > problem still exists. Either the patch is flawed or git-bisect gave me
> > the wrong commit. Any help would be appreciated.
>
> Try just reverting the commit that you bisected to, and double-check. If
> your bisect was flawed, there's no point even staring at the nop code ;)
>
> Linus
Thanks Linus.
I reverted the commit and the problem persits, so nops are definitely not the
problem. I started an new bisection but am now in a state that won't compile
due to errors. What do I do in that case?
David
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-02 12:08 ` David Sanders
@ 2008-09-02 18:12 ` Linus Torvalds
2008-09-02 18:44 ` David Sanders
0 siblings, 1 reply; 61+ messages in thread
From: Linus Torvalds @ 2008-09-02 18:12 UTC (permalink / raw)
To: David Sanders
Cc: linux-kernel, Jan Beulich, Ingo Molnar, Thomas Gleixner, Andi Kleen
On Tue, 2 Sep 2008, David Sanders wrote:
>
> I reverted the commit and the problem persits, so nops are definitely not the
> problem. I started an new bisection but am now in a state that won't compile
> due to errors. What do I do in that case?
You can try "git bisect skip", but in general the better choice is to just
do
git bisect visualize
to open up gitk with the current set of possible targets, and then just
pick a likely point by hand, and do
git reset --hard <sha1-of-the-thing-you-picked>
and try that one instead. There's some talk about this in "man git-bisect"
but maybe it's not very good.
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-02 18:12 ` Linus Torvalds
@ 2008-09-02 18:44 ` David Sanders
2008-09-03 11:09 ` Peter Zijlstra
0 siblings, 1 reply; 61+ messages in thread
From: David Sanders @ 2008-09-02 18:44 UTC (permalink / raw)
To: linux-kernel
Cc: Linus Torvalds, Jan Beulich, Ingo Molnar, Thomas Gleixner, Andi Kleen
On Tuesday 02 September 2008 14:12, Linus Torvalds wrote:
> On Tue, 2 Sep 2008, David Sanders wrote:
> > I reverted the commit and the problem persits, so nops are definitely not
> > the problem. I started an new bisection but am now in a state that won't
> > compile due to errors. What do I do in that case?
>
> You can try "git bisect skip", but in general the better choice is to just
> do
>
> git bisect visualize
>
> to open up gitk with the current set of possible targets, and then just
> pick a likely point by hand, and do
>
> git reset --hard <sha1-of-the-thing-you-picked>
>
> and try that one instead. There's some talk about this in "man git-bisect"
> but maybe it's not very good.
>
> Linus
OK thanks, I had to build a new version of git because the one installed with
my distribution was too old to have git bisect skip. I am trying to use the
gitk method you mentioned but it is going slow and on my screen gitk's fonts
are very hard to read.
David
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-02 18:44 ` David Sanders
@ 2008-09-03 11:09 ` Peter Zijlstra
2008-09-03 11:20 ` David Sanders
0 siblings, 1 reply; 61+ messages in thread
From: Peter Zijlstra @ 2008-09-03 11:09 UTC (permalink / raw)
To: linux
Cc: linux-kernel, Linus Torvalds, Jan Beulich, Ingo Molnar,
Thomas Gleixner, Andi Kleen
On Tue, 2008-09-02 at 14:44 -0400, David Sanders wrote:
> On Tuesday 02 September 2008 14:12, Linus Torvalds wrote:
> > On Tue, 2 Sep 2008, David Sanders wrote:
> > > I reverted the commit and the problem persits, so nops are definitely not
> > > the problem. I started an new bisection but am now in a state that won't
> > > compile due to errors. What do I do in that case?
> >
> > You can try "git bisect skip", but in general the better choice is to just
> > do
> >
> > git bisect visualize
> >
> > to open up gitk with the current set of possible targets, and then just
> > pick a likely point by hand, and do
> >
> > git reset --hard <sha1-of-the-thing-you-picked>
> >
> > and try that one instead. There's some talk about this in "man git-bisect"
> > but maybe it's not very good.
> >
> > Linus
>
> OK thanks, I had to build a new version of git because the one installed with
> my distribution was too old to have git bisect skip. I am trying to use the
> gitk method you mentioned but it is going slow and on my screen gitk's fonts
> are very hard to read.
Yeah - gitk's default fonts are a nightmare, I get a semi readable
interface by adding this to ~/.gitk
set mainfont {{dejavu sans mono} 10}
set textfont {{dejavu sans mono} 9}
set uifont {{dejavu sans mono} 10 bold}
But it seems the tcl/tk font rendering is pretty horrible all-round. I
generally prefer to use qgit for this reason.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-03 11:09 ` Peter Zijlstra
@ 2008-09-03 11:20 ` David Sanders
0 siblings, 0 replies; 61+ messages in thread
From: David Sanders @ 2008-09-03 11:20 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Zijlstra, Linus Torvalds, Jan Beulich, Ingo Molnar,
Thomas Gleixner, Andi Kleen
On Wednesday 03 September 2008 07:09, Peter Zijlstra wrote:
> Yeah - gitk's default fonts are a nightmare, I get a semi readable
> interface by adding this to ~/.gitk
>
> set mainfont {{dejavu sans mono} 10}
> set textfont {{dejavu sans mono} 9}
> set uifont {{dejavu sans mono} 10 bold}
>
> But it seems the tcl/tk font rendering is pretty horrible all-round. I
> generally prefer to use qgit for this reason.
Thanks that is a big improvement.
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-08-31 19:39 ` Linus Torvalds
@ 2008-09-05 15:38 ` David Sanders
2008-09-05 16:15 ` Jan Beulich
2008-09-05 16:30 ` Linus Torvalds
0 siblings, 2 replies; 61+ messages in thread
From: David Sanders @ 2008-09-05 15:38 UTC (permalink / raw)
To: linux-kernel
Cc: Linus Torvalds, Arjan van de Ven, Jan Beulich, Ingo Molnar,
Thomas Gleixner, Andi Kleen
On Sun, 31 Aug 2008, David Sanders wrote:
> I recently discovered that x86 kernels won't boot under Virtual PC.On Sun,
31 Aug 2008, David Sanders wrote:
On Sunday 31 August 2008 15:39, Linus Torvalds wrote:
> Well, it could be that Virtual PC raises a #UD exception in the virtual
> machine. In user space, that would just cause the kernel to kill the poor
> innocent victim. But when the kernel gets a #UD exception on what it
> expects to be a nop, it just won't work.
Sorry about the confusion. I was just learning git and applied a couple
patches wrong that lead me to believe I had not found the answer, when in
fact I had. The problem is the multibyte NOP instructions introduced into
the kernel in 2007. For 2.6.24-rc1 reverting the patch (32c464f5) corrects
the problem. But then of course we cannot use these instructions as we would
like. I propose the following patch which adds a boot-time parameter to not
use these multibyte NOPs in systems that are unprepared to deal with them.
The patch disables a optimization used in one place by commenting out some
lines in nop.h. Please comment.
x86: Fix to multibyte NOPs breaking Virtual PC (win)
To be applied to linux-2.6.27-rc5.
Signed-off-by: David Sanders <linux@sandersweb.net>
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 2763cb3..6a63e78 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -58,6 +58,15 @@ static int __init setup_noreplace_paravirt(char *str)
__setup("noreplace-paravirt", setup_noreplace_paravirt);
#endif
+static int intel_legacy_nops = 0;
+
+static int __init setup_intel_legacy_nops(char *str)
+{
+ intel_legacy_nops = 1;
+ return 1;
+}
+__setup("intel-legacy-nops", setup_intel_legacy_nops);
+
#define DPRINTK(fmt, args...) if (debug_alternative) \
printk(KERN_DEBUG fmt, args)
@@ -165,13 +174,14 @@ static const struct nop {
const unsigned char *const *find_nop_table(void)
{
const unsigned char *const *noptable = intel_nops;
- int i;
+ int i = 0;
- for (i = 0; noptypes[i].cpuid >= 0; i++) {
+ while (noptypes[i].cpuid >= 0 && !intel_legacy_nops) {
if (boot_cpu_has(noptypes[i].cpuid)) {
noptable = noptypes[i].noptable;
break;
}
+ i++;
}
return noptable;
}
diff --git a/include/asm-x86/nops.h b/include/asm-x86/nops.h
index ad0bedd..a6f0571 100644
--- a/include/asm-x86/nops.h
+++ b/include/asm-x86/nops.h
@@ -84,7 +84,7 @@
#define ASM_NOP6 K7_NOP6
#define ASM_NOP7 K7_NOP7
#define ASM_NOP8 K7_NOP8
-#elif defined(CONFIG_X86_P6_NOP)
+/* #elif defined(CONFIG_X86_P6_NOP)
#define ASM_NOP1 P6_NOP1
#define ASM_NOP2 P6_NOP2
#define ASM_NOP3 P6_NOP3
@@ -93,6 +93,7 @@
#define ASM_NOP6 P6_NOP6
#define ASM_NOP7 P6_NOP7
#define ASM_NOP8 P6_NOP8
+*/
#elif defined(CONFIG_X86_64)
#define ASM_NOP1 K8_NOP1
#define ASM_NOP2 K8_NOP2
^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-05 15:38 ` David Sanders
@ 2008-09-05 16:15 ` Jan Beulich
2008-09-05 16:39 ` Linus Torvalds
2008-09-05 20:12 ` H. Peter Anvin
2008-09-05 16:30 ` Linus Torvalds
1 sibling, 2 replies; 61+ messages in thread
From: Jan Beulich @ 2008-09-05 16:15 UTC (permalink / raw)
To: linux
Cc: Ingo Molnar, Andi Kleen, Arjan van de Ven, Thomas Gleixner,
Linus Torvalds, linux-kernel
>--- a/include/asm-x86/nops.h
>+++ b/include/asm-x86/nops.h
>@@ -84,7 +84,7 @@
> #define ASM_NOP6 K7_NOP6
> #define ASM_NOP7 K7_NOP7
> #define ASM_NOP8 K7_NOP8
>-#elif defined(CONFIG_X86_P6_NOP)
>+/* #elif defined(CONFIG_X86_P6_NOP)
> #define ASM_NOP1 P6_NOP1
> #define ASM_NOP2 P6_NOP2
> #define ASM_NOP3 P6_NOP3
>@@ -93,6 +93,7 @@
> #define ASM_NOP6 P6_NOP6
> #define ASM_NOP7 P6_NOP7
> #define ASM_NOP8 P6_NOP8
>+*/
> #elif defined(CONFIG_X86_64)
> #define ASM_NOP1 K8_NOP1
> #define ASM_NOP2 K8_NOP2
I disagree here: If I configure a 686+ kernel, I expect these NOPs to be
that way (and to work). If you want to run on something that's not
compliant, you just shouldn't configure your kernel that way.
Jan
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-05 15:38 ` David Sanders
2008-09-05 16:15 ` Jan Beulich
@ 2008-09-05 16:30 ` Linus Torvalds
2008-09-05 17:55 ` Andi Kleen
1 sibling, 1 reply; 61+ messages in thread
From: Linus Torvalds @ 2008-09-05 16:30 UTC (permalink / raw)
To: David Sanders
Cc: linux-kernel, Arjan van de Ven, Jan Beulich, Ingo Molnar,
Thomas Gleixner, Andi Kleen
On Fri, 5 Sep 2008, David Sanders wrote:
>
> The patch disables a optimization used in one place by commenting out some
> lines in nop.h. Please comment.
Hmm.. I'm not a huge fan of the ASM_NOP mess, but you also disable it for
64-bit x86 too.
On 32-bit, at least the generic nops are fairly reasonable, but the
default nops for 64-bit really look pretty sad, and the P6 nops really do
look better.
So I would suggest perhaps moving the static P6 nop selection into the
CONFIG_X86_64 thing.
The alternative is to just get rid of that static nop selection, and just
have two cases: 32-bit and 64-bit, and just pick obviously safe cases for
them.
So I think that particular part would be better off with changing the
Kconfig language instead. Ie something like this..
(I removed the 32-bit CPU's from the choices, except for MPENTIUM4 that
really should be merged with MPSC - the difference between MPENTIUM4 and
MPSC seems to be just a totally bogus 32-bit vs 64-bit thing. Yes, yes,
there are PENTIUM4's without 64-bit, but there are also Prescott chips
that run 32-bit kernels, so the thing is a bit confused.
Linus
---
arch/x86/Kconfig.cpu | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 2c518fb..b225219 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -382,14 +382,17 @@ config X86_OOSTORE
# P6_NOPs are a relatively minor optimization that require a family >=
# 6 processor, except that it is broken on certain VIA chips.
# Furthermore, AMD chips prefer a totally different sequence of NOPs
-# (which work on all CPUs). As a result, disallow these if we're
-# compiling X86_GENERIC but not X86_64 (these NOPs do work on all
-# x86-64 capable chips); the list of processors in the right-hand clause
-# are the cores that benefit from this optimization.
+# (which work on all CPUs). In addition, it looks like Virtual PC
+# does not understand them.
+#
+# As a result, disallow these if we're not compiling for X86_64 (these
+# NOPs do work on all x86-64 capable chips); the list of processors in
+# the right-hand clause are the cores that benefit from this optimization.
#
config X86_P6_NOP
def_bool y
- depends on (X86_64 || !X86_GENERIC) && (M686 || MPENTIUMII || MPENTIUMIII || MPENTIUMM || MCORE2 || MPENTIUM4 || MPSC)
+ depends on X86_64
+ depends on (MCORE2 || MPENTIUM4 || MPSC)
config X86_TSC
def_bool y
^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-05 16:15 ` Jan Beulich
@ 2008-09-05 16:39 ` Linus Torvalds
2008-09-05 18:43 ` Ingo Molnar
2008-09-05 19:08 ` Jeremy Fitzhardinge
2008-09-05 20:12 ` H. Peter Anvin
1 sibling, 2 replies; 61+ messages in thread
From: Linus Torvalds @ 2008-09-05 16:39 UTC (permalink / raw)
To: Jan Beulich
Cc: linux, Ingo Molnar, Andi Kleen, Arjan van de Ven,
Thomas Gleixner, Linux Kernel Mailing List
On Fri, 5 Sep 2008, Jan Beulich wrote:
>
> I disagree here: If I configure a 686+ kernel, I expect these NOPs to be
> that way (and to work). If you want to run on something that's not
> compliant, you just shouldn't configure your kernel that way.
Well, if you actually do a
git grep 'ASM_NOP[0-9]'
you'll find that just the _definitions_ of those things are the bulk of it
BY FAR, and that there doesn't seem to be a single user that cares even
remotely about performance.
So I actually think that the whole thing is a waste of time. We should
probably
- pick a single set of NOP's per 32-bit/64-bit (since the good nops in
32-bit aren't 64-bit instructions at all, so we do want different nops
depending on _that_)
The whole static choice by microarchitecture is pure garbage.
- Probably also just declare that those default nops are single
instructions, just so that we never even have to think about it from a
dynamic replacement angle.
Look at the uses again, and realize that it really is just pure garbage
to have this kind of complex and subtle stuff going on.
- Move the optimized nop definitions (K7_NOPx etc) to the only place that
cares - asm/x86/kernel/alternative.c. When we do things _dynamically_,
it can actually make sense to pick a nop more precisely, but for this
whole static thing it's just a pain.
IOW, if it actually _worked_ reasonably, I wouldn't care. But clearly it
doesn't. And once it's not working reasonably, it should be fixed.
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-05 16:30 ` Linus Torvalds
@ 2008-09-05 17:55 ` Andi Kleen
0 siblings, 0 replies; 61+ messages in thread
From: Andi Kleen @ 2008-09-05 17:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Sanders, linux-kernel, Arjan van de Ven, Jan Beulich,
Ingo Molnar, Thomas Gleixner, Andi Kleen
On Fri, Sep 05, 2008 at 09:30:14AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 5 Sep 2008, David Sanders wrote:
> >
> > The patch disables a optimization used in one place by commenting out some
> > lines in nop.h. Please comment.
>
> Hmm.. I'm not a huge fan of the ASM_NOP mess, but you also disable it for
> 64-bit x86 too.
Heh -- I originally only added it because you're asked for it ...
Yes going back to some simple generic nops and avoid all these problems
would be a great thing.
-Andi
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-05 16:39 ` Linus Torvalds
@ 2008-09-05 18:43 ` Ingo Molnar
2008-09-05 20:06 ` H. Peter Anvin
2008-09-05 19:08 ` Jeremy Fitzhardinge
1 sibling, 1 reply; 61+ messages in thread
From: Ingo Molnar @ 2008-09-05 18:43 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jan Beulich, linux, Andi Kleen, Arjan van de Ven,
Thomas Gleixner, Linux Kernel Mailing List, H. Peter Anvin
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> - Move the optimized nop definitions (K7_NOPx etc) to the only place that
> cares - asm/x86/kernel/alternative.c. When we do things _dynamically_,
> it can actually make sense to pick a nop more precisely, but for this
> whole static thing it's just a pain.
>
> IOW, if it actually _worked_ reasonably, I wouldn't care. But clearly
> it doesn't. And once it's not working reasonably, it should be fixed.
yes - we had 3-4 tries already and while it looked worthwile initially
it's clearly not showing signs of getting more robust and whatever
benefits there might be slightly better NOPs is dwarved by all these
robustness problems. Peter?
Ingo
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-05 16:39 ` Linus Torvalds
2008-09-05 18:43 ` Ingo Molnar
@ 2008-09-05 19:08 ` Jeremy Fitzhardinge
1 sibling, 0 replies; 61+ messages in thread
From: Jeremy Fitzhardinge @ 2008-09-05 19:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jan Beulich, linux, Ingo Molnar, Andi Kleen, Arjan van de Ven,
Thomas Gleixner, Linux Kernel Mailing List
Linus Torvalds wrote:
> On Fri, 5 Sep 2008, Jan Beulich wrote:
>
>> I disagree here: If I configure a 686+ kernel, I expect these NOPs to be
>> that way (and to work). If you want to run on something that's not
>> compliant, you just shouldn't configure your kernel that way.
>>
>
> Well, if you actually do a
>
> git grep 'ASM_NOP[0-9]'
>
> you'll find that just the _definitions_ of those things are the bulk of it
> BY FAR, and that there doesn't seem to be a single user that cares even
> remotely about performance.
>
Well, the paravirt_ops patching uses multibyte nops to pad out the
unused space in a patch site, and they're generally on hot paths
(otherwise we wouldn't bother with patching). But even then I don't
think the particular nop chosen matters all that much, and even if it
did using the dumb redundant prefix long nops seems to be as good as or
better than the p6 nops. The "call mcount" patching ftrace wants to do
would also be pretty common.
> So I actually think that the whole thing is a waste of time. We should
> probably
>
> - pick a single set of NOP's per 32-bit/64-bit (since the good nops in
> 32-bit aren't 64-bit instructions at all, so we do want different nops
> depending on _that_)
>
> The whole static choice by microarchitecture is pure garbage.
>
> - Probably also just declare that those default nops are single
> instructions, just so that we never even have to think about it from a
> dynamic replacement angle.
>
Yes, that would be a good idea.
> - Move the optimized nop definitions (K7_NOPx etc) to the only place that
> cares - asm/x86/kernel/alternative.c. When we do things _dynamically_,
> it can actually make sense to pick a nop more precisely, but for this
> whole static thing it's just a pain.
>
Yep. We could run the p6 nops with an exception handler to see if the
cpu actually supports them or not. And if not, just fall back to
something simple and good enough.
J
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-05 18:43 ` Ingo Molnar
@ 2008-09-05 20:06 ` H. Peter Anvin
0 siblings, 0 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-05 20:06 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Jan Beulich, linux, Andi Kleen, Arjan van de Ven,
Thomas Gleixner, Linux Kernel Mailing List
Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> - Move the optimized nop definitions (K7_NOPx etc) to the only place that
>> cares - asm/x86/kernel/alternative.c. When we do things _dynamically_,
>> it can actually make sense to pick a nop more precisely, but for this
>> whole static thing it's just a pain.
>>
>> IOW, if it actually _worked_ reasonably, I wouldn't care. But clearly
>> it doesn't. And once it's not working reasonably, it should be fixed.
>
> yes - we had 3-4 tries already and while it looked worthwile initially
> it's clearly not showing signs of getting more robust and whatever
> benefits there might be slightly better NOPs is dwarved by all these
> robustness problems. Peter?
There is already a fix for this based on a first-principles test in tip.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-05 16:15 ` Jan Beulich
2008-09-05 16:39 ` Linus Torvalds
@ 2008-09-05 20:12 ` H. Peter Anvin
1 sibling, 0 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-05 20:12 UTC (permalink / raw)
To: Jan Beulich
Cc: linux, Ingo Molnar, Andi Kleen, Arjan van de Ven,
Thomas Gleixner, Linus Torvalds, linux-kernel
Jan Beulich wrote:
>
> I disagree here: If I configure a 686+ kernel, I expect these NOPs to be
> that way (and to work). If you want to run on something that's not
> compliant, you just shouldn't configure your kernel that way.
>
Okay, we do not generate P6 NOPs statically if CONFIG_X86_GENERIC_CPU is
enabled -- unless, of course gcc/binutils generates them, which they now
do for certain CPU types. If you are selecting a specific CPU *and* you
don't select GENERIC, you should get valid code for the selected CPU only.
As far as using them dynamically, there is code in -tip that determines
dynamically and explicitly if the long NOPs are available, and only uses
them if they are.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
[not found] ` <48C1C156.9080003@zytor.com>
@ 2008-09-07 20:07 ` David Sanders
2008-09-07 23:22 ` David Sanders
0 siblings, 1 reply; 61+ messages in thread
From: David Sanders @ 2008-09-07 20:07 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-kernel, the arch/x86 maintainers
On Friday 05 September 2008 19:31, H. Peter Anvin wrote:
> David Sanders wrote:
> > I recently discovered that x86 kernels won't boot under Virtual PC. In
> > this case paravirt was not built into the kernel. The kernel just
> > "hangs" on attempted boot with no error messages. Git-bisect pinpointed
> > the following commit as the problem:
>
> Hi David,
>
> Could you please confirm if the tip kernel solves the problem?
>
> Either that or apply this patch series to mainline; I'd like to promote
> this to urgent and send it to Linus for inclusion in 2.6.27, but I need
> verification as quickly as possible.
>
> -hpa
Peter, sorry about delay in replying I was out of town for weekend. I will
apply your patch and git back to you on results. A quick look a the patches
indicates that nop.h and the users of nop.h are not addressed so I may have
to combine your patches with Linus's Kconfig patch to get a working kernel.
David
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-07 20:07 ` David Sanders
@ 2008-09-07 23:22 ` David Sanders
2008-09-08 1:48 ` H. Peter Anvin
0 siblings, 1 reply; 61+ messages in thread
From: David Sanders @ 2008-09-07 23:22 UTC (permalink / raw)
To: linux-kernel, H. Peter Anvin, Linus Torvalds
Cc: the arch/x86 maintainers, Andi Kleen
On Friday 05 September 2008 19:31, H. Peter Anvin wrote:
> David Sanders wrote:
> > I recently discovered that x86 kernels won't boot under Virtual PC. In
>
> Could you please confirm if the tip kernel solves the problem?
>
Yes the patch you supplied (and now in Linus's tree) fixes (part) of the problem.
In order to get a working kernel I also need a patch for the nops.h issue.
I have tested and confirmed that the patch posted by Linus works and finally
solves the problem with virtual PC.
Linus please apply your patch (which I quote below).
---
arch/x86/Kconfig.cpu | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 2c518fb..b225219 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -382,14 +382,17 @@ config X86_OOSTORE
# P6_NOPs are a relatively minor optimization that require a family >=
# 6 processor, except that it is broken on certain VIA chips.
# Furthermore, AMD chips prefer a totally different sequence of NOPs
-# (which work on all CPUs). As a result, disallow these if we're
-# compiling X86_GENERIC but not X86_64 (these NOPs do work on all
-# x86-64 capable chips); the list of processors in the right-hand clause
-# are the cores that benefit from this optimization.
+# (which work on all CPUs). In addition, it looks like Virtual PC
+# does not understand them.
+#
+# As a result, disallow these if we're not compiling for X86_64 (these
+# NOPs do work on all x86-64 capable chips); the list of processors in
+# the right-hand clause are the cores that benefit from this optimization.
#
config X86_P6_NOP
def_bool y
- depends on (X86_64 || !X86_GENERIC) && (M686 || MPENTIUMII || MPENTIUMIII || MPENTIUMM || MCORE2 || MPENTIUM4 || MPSC)
+ depends on X86_64
+ depends on (MCORE2 || MPENTIUM4 || MPSC)
config X86_TSC
def_bool y
^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-07 23:22 ` David Sanders
@ 2008-09-08 1:48 ` H. Peter Anvin
2008-09-08 2:49 ` David Sanders
0 siblings, 1 reply; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 1:48 UTC (permalink / raw)
To: linux; +Cc: linux-kernel, Linus Torvalds, the arch/x86 maintainers, Andi Kleen
David Sanders wrote:
>
> Yes the patch you supplied (and now in Linus's tree) fixes (part) of the problem.
> In order to get a working kernel I also need a patch for the nops.h issue.
> I have tested and confirmed that the patch posted by Linus works and finally
> solves the problem with virtual PC.
>
> Linus please apply your patch (which I quote below).
No, please don't. Instead, David, please enable CONFIG_X86_GENERIC.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 1:48 ` H. Peter Anvin
@ 2008-09-08 2:49 ` David Sanders
2008-09-08 4:04 ` H. Peter Anvin
0 siblings, 1 reply; 61+ messages in thread
From: David Sanders @ 2008-09-08 2:49 UTC (permalink / raw)
To: linux-kernel
Cc: H. Peter Anvin, Linus Torvalds, the arch/x86 maintainers, Andi Kleen
On Sunday 07 September 2008 21:48, H. Peter Anvin wrote:
> David Sanders wrote:
> > Yes the patch you supplied (and now in Linus's tree) fixes (part) of the
> > problem. In order to get a working kernel I also need a patch for the
> > nops.h issue. I have tested and confirmed that the patch posted by Linus
> > works and finally solves the problem with virtual PC.
> >
> > Linus please apply your patch (which I quote below).
>
> No, please don't. Instead, David, please enable CONFIG_X86_GENERIC.
>
I checked the distribution I'm using (debian) and the kernel shipped with it
does not have CONFIG_X86_GENERIC set. This means _when_ they ship a 2.6.27
kernel it won't work with Virtual PC so I won't be able to even install it.
However, with Linus's patch I am guaranteed to work for all kernels built for
X86_32 and even for X86_64 because in that case the virtual environment will
support the multibyte NOPs. I need Linus's fix in order to support the
Linux-using virtual pc community. I don't have the resources to lobby each
individual distribution about their kernel config. I want it to just work.
David
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 2:49 ` David Sanders
@ 2008-09-08 4:04 ` H. Peter Anvin
2008-09-08 9:42 ` Andi Kleen
` (2 more replies)
0 siblings, 3 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 4:04 UTC (permalink / raw)
To: linux; +Cc: linux-kernel, Linus Torvalds, the arch/x86 maintainers, Andi Kleen
David Sanders wrote:
> I checked the distribution I'm using (debian) and the kernel shipped with it
> does not have CONFIG_X86_GENERIC set. This means _when_ they ship a 2.6.27
> kernel it won't work with Virtual PC so I won't be able to even install it.
Then please file a bug report with Debian.
> However, with Linus's patch I am guaranteed to work for all kernels built for
> X86_32 and even for X86_64 because in that case the virtual environment will
> support the multibyte NOPs. I need Linus's fix in order to support the
> Linux-using virtual pc community. I don't have the resources to lobby each
> individual distribution about their kernel config. I want it to just work.
Under that logic we shouldn't even have CPU configurables, since you
want it to "just work" whatever crap you're running on. That is EXACTLY
what CONFIG_X86_GENERIC means, and the fact that any particular
distribution is broken with respect to not enabling it is a bug in that
distribution, and not grounds for breaking the upstream kernel.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 4:04 ` H. Peter Anvin
@ 2008-09-08 9:42 ` Andi Kleen
2008-09-08 13:25 ` David Sanders
2008-09-08 15:09 ` Linus Torvalds
2 siblings, 0 replies; 61+ messages in thread
From: Andi Kleen @ 2008-09-08 9:42 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux, linux-kernel, Linus Torvalds, the arch/x86 maintainers,
Andi Kleen
> Under that logic we shouldn't even have CPU configurables, since you
Just for optimization.
> want it to "just work" whatever crap you're running on. That is EXACTLY
> what CONFIG_X86_GENERIC means, and the fact that any particular
At least when I introduced X86_GENERIC it was just an optimization,
not a requirement.
That is the kernel pretty much always did "just work"
(with only a very few exceptions like PAE vs non PAE) on all
CPUs. The CPU configs also just specified optimizations, not correctness.
The code for all CPUs used to be always there.
X86_GENERIC was mostly just to do things like always use
the largest cache alignment.
I think someone changed that recently, but imho that wasn't
an improvement. As you can see it just causes endless support
problems.
> distribution is broken with respect to not enabling it is a bug in that
> distribution, and not grounds for breaking the upstream kernel.
Well it's more like that you guys changed the semantics
without warnings the distributions. I'm not sure you can blame
Debian for that.
-Andi
--
ak@linux.intel.com
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 4:04 ` H. Peter Anvin
2008-09-08 9:42 ` Andi Kleen
@ 2008-09-08 13:25 ` David Sanders
2008-09-08 15:09 ` Linus Torvalds
2 siblings, 0 replies; 61+ messages in thread
From: David Sanders @ 2008-09-08 13:25 UTC (permalink / raw)
To: linux-kernel, H. Peter Anvin
Cc: Linus Torvalds, the arch/x86 maintainers, Andi Kleen
On Monday 08 September 2008 00:04, H. Peter Anvin wrote:
> David Sanders wrote:
> > I checked the distribution I'm using (debian) and the kernel shipped with
> > it does not have CONFIG_X86_GENERIC set. This means _when_ they ship a
> > 2.6.27 kernel it won't work with Virtual PC so I won't be able to even
> > install it.
>
> Then please file a bug report with Debian.
Well, OK I could do that. But I can't bug every distribution in existence for
the same thing.
>
> > However, with Linus's patch I am guaranteed to work for all kernels built
> > for X86_32 and even for X86_64 because in that case the virtual
> > environment will support the multibyte NOPs. I need Linus's fix in order
> > to support the Linux-using virtual pc community. I don't have the
> > resources to lobby each individual distribution about their kernel
> > config. I want it to just work.
>
> Under that logic we shouldn't even have CPU configurables, since you
> want it to "just work" whatever crap you're running on. That is EXACTLY
> what CONFIG_X86_GENERIC means, and the fact that any particular
> distribution is broken with respect to not enabling it is a bug in that
> distribution, and not grounds for breaking the upstream kernel.
>
> -hpa
I don't see that Linus's patch breaks the upstream kernel. Just the opposite,
you go and determine in alternative.c that the processor doesn't support NOPL
and then go ahead and use it anyway in nops.h. That makes no sense to me.
Could we use the result of find_nop_table() instead of nops.h?
David
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 4:04 ` H. Peter Anvin
2008-09-08 9:42 ` Andi Kleen
2008-09-08 13:25 ` David Sanders
@ 2008-09-08 15:09 ` Linus Torvalds
2008-09-08 15:23 ` Ingo Molnar
2008-09-08 15:45 ` Andi Kleen
2 siblings, 2 replies; 61+ messages in thread
From: Linus Torvalds @ 2008-09-08 15:09 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
On Sun, 7 Sep 2008, H. Peter Anvin wrote:
>
> Under that logic we shouldn't even have CPU configurables, since you want it
> to "just work" whatever crap you're running on. That is EXACTLY what
> CONFIG_X86_GENERIC means
I dunno.. Event he help-text doesn't actually agree with that:
config X86_GENERIC
bool "Generic x86 support"
depends on X86_32
help
Instead of just including optimizations for the selected
x86 variant (e.g. PII, Crusoe or Athlon), include some more
generic optimizations as well. This will make the kernel
perform better on x86 CPUs other than that selected.
This is really intended for distributors who need more
generic optimizations.
Also, quite frankly, while the CPU processor type message says
The kernel will not necessarily run on earlier architectures than
the one you have chosen, e.g. a Pentium optimized kernel will run on
a PPro, but not necessarily on a i486.
I thought you agreed that CPU virtualization can be a problem? That was
the whole excuse for why the dynamic code was changed. Why would it not be
true for the static code?
The fact is, if you want to run on a Core2 or other modern CPU, then
"Virtual PC" is apparently buggy in this respect. You worked around it for
the dynamic choice - but that's totally _pointless_ if you then don't want
to work around it for the static one.
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:09 ` Linus Torvalds
@ 2008-09-08 15:23 ` Ingo Molnar
2008-09-08 15:36 ` H. Peter Anvin
` (2 more replies)
2008-09-08 15:45 ` Andi Kleen
1 sibling, 3 replies; 61+ messages in thread
From: Ingo Molnar @ 2008-09-08 15:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, linux, linux-kernel, the arch/x86 maintainers,
Andi Kleen
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sun, 7 Sep 2008, H. Peter Anvin wrote:
> >
> > Under that logic we shouldn't even have CPU configurables, since you want it
> > to "just work" whatever crap you're running on. That is EXACTLY what
> > CONFIG_X86_GENERIC means
>
> I dunno.. Event he help-text doesn't actually agree with that:
>
> config X86_GENERIC
> bool "Generic x86 support"
> depends on X86_32
> help
> Instead of just including optimizations for the selected
> x86 variant (e.g. PII, Crusoe or Athlon), include some more
> generic optimizations as well. This will make the kernel
> perform better on x86 CPUs other than that selected.
>
> This is really intended for distributors who need more
> generic optimizations.
>
> Also, quite frankly, while the CPU processor type message says
>
> The kernel will not necessarily run on earlier architectures than
> the one you have chosen, e.g. a Pentium optimized kernel will run on
> a PPro, but not necessarily on a i486.
>
> I thought you agreed that CPU virtualization can be a problem? That
> was the whole excuse for why the dynamic code was changed. Why would
> it not be true for the static code?
>
> The fact is, if you want to run on a Core2 or other modern CPU, then
> "Virtual PC" is apparently buggy in this respect. You worked around it
> for the dynamic choice - but that's totally _pointless_ if you then
> don't want to work around it for the static one.
yes. X86_P6_NOPS is a totally insignificant optimization and if it makes
_any_ CPU not boot (be that virtual or real), then it's frankly not
worth it.
David, exactly how does the kernel fail to boot with latest -git?
(v2.6.27-rc5-313-g64f996f or later) Does detect_nopl() run? It really
should, and it should detect the non-working instructions.
Ingo
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:23 ` Ingo Molnar
@ 2008-09-08 15:36 ` H. Peter Anvin
2008-09-08 15:38 ` David Sanders
2008-09-08 15:38 ` H. Peter Anvin
2 siblings, 0 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 15:36 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, linux, linux-kernel, the arch/x86 maintainers,
Andi Kleen
Ingo Molnar wrote:
>
> yes. X86_P6_NOPS is a totally insignificant optimization and if it makes
> _any_ CPU not boot (be that virtual or real), then it's frankly not
> worth it.
>
> David, exactly how does the kernel fail to boot with latest -git?
> (v2.6.27-rc5-313-g64f996f or later) Does detect_nopl() run? It really
> should, and it should detect the non-working instructions.
>
Okay, a few things here...
1. First, I wrote up a patch yesterday to update the CONFIG_X86_GENERIC
description and to make it "default y". It is currently on
x86/defconfig, but I think it should be promoted to mainline immediately.
2. X86_P6_NOPS is not the only source of static NOPLs. If gcc is set to
optimize for specific architectures, then gcc/binutils will generate
static NOPLs. The only way we can prevent that is by not using specific
-march options, as far as I can tell.
3. I'm not positive that CONFIG_X86_GENERIC currently avoid all cases of
(2), but it obviously should. I will verify that today and add a
followup patch to the Makefiles if necessary.
Given all of this, I really think that putting this on
CONFIG_X86_GENERIC, *AND* making CONFIG_X86_GENERIC the default is the
right choice.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:23 ` Ingo Molnar
2008-09-08 15:36 ` H. Peter Anvin
@ 2008-09-08 15:38 ` David Sanders
2008-09-08 15:38 ` H. Peter Anvin
2 siblings, 0 replies; 61+ messages in thread
From: David Sanders @ 2008-09-08 15:38 UTC (permalink / raw)
To: linux-kernel
Cc: Ingo Molnar, Linus Torvalds, H. Peter Anvin,
the arch/x86 maintainers, Andi Kleen
On Monday 08 September 2008 11:23, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > On Sun, 7 Sep 2008, H. Peter Anvin wrote:
> > > Under that logic we shouldn't even have CPU configurables, since you
> > > want it to "just work" whatever crap you're running on. That is
> > > EXACTLY what CONFIG_X86_GENERIC means
> >
> > I dunno.. Event he help-text doesn't actually agree with that:
> >
> > config X86_GENERIC
> > bool "Generic x86 support"
> > depends on X86_32
> > help
> > Instead of just including optimizations for the selected
> > x86 variant (e.g. PII, Crusoe or Athlon), include some more
> > generic optimizations as well. This will make the kernel
> > perform better on x86 CPUs other than that selected.
> >
> > This is really intended for distributors who need more
> > generic optimizations.
> >
> > Also, quite frankly, while the CPU processor type message says
> >
> > The kernel will not necessarily run on earlier architectures
> > than the one you have chosen, e.g. a Pentium optimized kernel will run on
> > a PPro, but not necessarily on a i486.
> >
> > I thought you agreed that CPU virtualization can be a problem? That
> > was the whole excuse for why the dynamic code was changed. Why would
> > it not be true for the static code?
> >
> > The fact is, if you want to run on a Core2 or other modern CPU, then
> > "Virtual PC" is apparently buggy in this respect. You worked around it
> > for the dynamic choice - but that's totally _pointless_ if you then
> > don't want to work around it for the static one.
>
> yes. X86_P6_NOPS is a totally insignificant optimization and if it makes
> _any_ CPU not boot (be that virtual or real), then it's frankly not
> worth it.
>
> David, exactly how does the kernel fail to boot with latest -git?
> (v2.6.27-rc5-313-g64f996f or later) Does detect_nopl() run? It really
> should, and it should detect the non-working instructions.
>
Ingo,
With CONFIG_X86_GENERIC=y, the latest v2.6.27 in Linus's tree boots fine. But
if you don't select that option (and some distributions don't) it won't boot
at all. It just hangs (blank screen) with no error messages and nothing in
dmesg. I assume it is hitting one of the ASM_NOP? instructions.
David
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:23 ` Ingo Molnar
2008-09-08 15:36 ` H. Peter Anvin
2008-09-08 15:38 ` David Sanders
@ 2008-09-08 15:38 ` H. Peter Anvin
2 siblings, 0 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 15:38 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, linux, linux-kernel, the arch/x86 maintainers,
Andi Kleen
Ingo Molnar wrote:
>>
>> I thought you agreed that CPU virtualization can be a problem? That
>> was the whole excuse for why the dynamic code was changed. Why would
>> it not be true for the static code?
>>
>> The fact is, if you want to run on a Core2 or other modern CPU, then
>> "Virtual PC" is apparently buggy in this respect. You worked around it
>> for the dynamic choice - but that's totally _pointless_ if you then
>> don't want to work around it for the static one.
>
> yes. X86_P6_NOPS is a totally insignificant optimization and if it makes
> _any_ CPU not boot (be that virtual or real), then it's frankly not
> worth it.
>
> David, exactly how does the kernel fail to boot with latest -git?
> (v2.6.27-rc5-313-g64f996f or later) Does detect_nopl() run? It really
> should, and it should detect the non-working instructions.
>
It almost certainly never gets as far as detect_nopl().
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:45 ` Andi Kleen
@ 2008-09-08 15:43 ` H. Peter Anvin
2008-09-08 15:50 ` H. Peter Anvin
` (2 more replies)
0 siblings, 3 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 15:43 UTC (permalink / raw)
To: Andi Kleen
Cc: Linus Torvalds, linux, linux-kernel, the arch/x86 maintainers,
Andi Kleen
Andi Kleen wrote:
> On Mon, Sep 08, 2008 at 08:09:48AM -0700, Linus Torvalds wrote:
>> On Sun, 7 Sep 2008, H. Peter Anvin wrote:
>>> Under that logic we shouldn't even have CPU configurables, since you want it
>>> to "just work" whatever crap you're running on. That is EXACTLY what
>>> CONFIG_X86_GENERIC means
>> I dunno.. Event he help-text doesn't actually agree with that:
>
> The help text matches in how I wrote this option originally.
> The original use case was the 128 byte P4 cache lines.
>
The help text is indeed out of date. I did a patch yesterday to, among
other things, update it; I also want to verify that we are disabling all
options that can cause gcc or binutils to generate nopl's; I plan to
push it today.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:09 ` Linus Torvalds
2008-09-08 15:23 ` Ingo Molnar
@ 2008-09-08 15:45 ` Andi Kleen
2008-09-08 15:43 ` H. Peter Anvin
1 sibling, 1 reply; 61+ messages in thread
From: Andi Kleen @ 2008-09-08 15:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, linux, linux-kernel, the arch/x86 maintainers,
Andi Kleen
On Mon, Sep 08, 2008 at 08:09:48AM -0700, Linus Torvalds wrote:
> On Sun, 7 Sep 2008, H. Peter Anvin wrote:
> >
> > Under that logic we shouldn't even have CPU configurables, since you want it
> > to "just work" whatever crap you're running on. That is EXACTLY what
> > CONFIG_X86_GENERIC means
>
> I dunno.. Event he help-text doesn't actually agree with that:
The help text matches in how I wrote this option originally.
The original use case was the 128 byte P4 cache lines.
-Andi
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:43 ` H. Peter Anvin
@ 2008-09-08 15:50 ` H. Peter Anvin
2008-09-08 15:50 ` Andi Kleen
2008-09-08 16:07 ` Linus Torvalds
2 siblings, 0 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 15:50 UTC (permalink / raw)
To: Andi Kleen
Cc: Linus Torvalds, linux, linux-kernel, the arch/x86 maintainers,
Andi Kleen
H. Peter Anvin wrote:
>
> The help text is indeed out of date. I did a patch yesterday to, among
> other things, update it; I also want to verify that we are disabling all
> options that can cause gcc or binutils to generate nopl's; I plan to
> push it today.
>
OK, turns out that is already happending, by virtue of:
# add at the end to overwrite eventual tuning options from earlier
# cpu entries
cflags-$(CONFIG_X86_GENERIC) += $(call tune,generic,$(call tune,i686))
-mtune=generic on 32-bit CPUs disable NOPL generation, and any
gcc/binutils combo too old to have -mtune=generic won't generate them at
all.
I think I verified this some time in the past, but I just had to refresh
my memory. This was a major reason to put this functionality on
CONFIG_X86_GENERIC.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:43 ` H. Peter Anvin
2008-09-08 15:50 ` H. Peter Anvin
@ 2008-09-08 15:50 ` Andi Kleen
2008-09-08 15:50 ` H. Peter Anvin
2008-09-08 16:07 ` Linus Torvalds
2 siblings, 1 reply; 61+ messages in thread
From: Andi Kleen @ 2008-09-08 15:50 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andi Kleen, Linus Torvalds, linux, linux-kernel,
the arch/x86 maintainers, Andi Kleen
> The help text is indeed out of date. I did a patch yesterday to, among
> other things, update it; I also want to verify that we are disabling all
> options that can cause gcc or binutils to generate nopl's; I plan to
> push it today.
You (or whoever did those changes) likely broke a lot of distribution setups
subtly then. Hopefully the changes were worth that.
-Andi
--
ak@linux.intel.com
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:50 ` Andi Kleen
@ 2008-09-08 15:50 ` H. Peter Anvin
2008-09-08 15:57 ` Andi Kleen
0 siblings, 1 reply; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 15:50 UTC (permalink / raw)
To: Andi Kleen
Cc: Linus Torvalds, linux, linux-kernel, the arch/x86 maintainers,
Andi Kleen
Andi Kleen wrote:
>> The help text is indeed out of date. I did a patch yesterday to, among
>> other things, update it; I also want to verify that we are disabling all
>> options that can cause gcc or binutils to generate nopl's; I plan to
>> push it today.
>
> You (or whoever did those changes) likely broke a lot of distribution setups
> subtly then. Hopefully the changes were worth that.
Likely broke a lot of distribution setups how?
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:57 ` Andi Kleen
@ 2008-09-08 15:54 ` H. Peter Anvin
0 siblings, 0 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 15:54 UTC (permalink / raw)
To: Andi Kleen
Cc: Linus Torvalds, linux, linux-kernel, the arch/x86 maintainers,
Andi Kleen
Andi Kleen wrote:
> On Mon, Sep 08, 2008 at 08:50:46AM -0700, H. Peter Anvin wrote:
>> Andi Kleen wrote:
>>>> The help text is indeed out of date. I did a patch yesterday to, among
>>>> other things, update it; I also want to verify that we are disabling all
>>>> options that can cause gcc or binutils to generate nopl's; I plan to
>>>> push it today.
>>> You (or whoever did those changes) likely broke a lot of distribution
>>> setups subtly then. Hopefully the changes were worth that.
>> Likely broke a lot of distribution setups how?
>
> Previously they could set CPU x and it would still run on other CPUs
> even if that option was not set. If that's not the case anymore then
> they will have some unhappy users once they update their kernels.
>
That was broken long before by the gcc and binutils authors.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:50 ` H. Peter Anvin
@ 2008-09-08 15:57 ` Andi Kleen
2008-09-08 15:54 ` H. Peter Anvin
0 siblings, 1 reply; 61+ messages in thread
From: Andi Kleen @ 2008-09-08 15:57 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andi Kleen, Linus Torvalds, linux, linux-kernel,
the arch/x86 maintainers, Andi Kleen
On Mon, Sep 08, 2008 at 08:50:46AM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >>The help text is indeed out of date. I did a patch yesterday to, among
> >>other things, update it; I also want to verify that we are disabling all
> >>options that can cause gcc or binutils to generate nopl's; I plan to
> >>push it today.
> >
> >You (or whoever did those changes) likely broke a lot of distribution
> >setups subtly then. Hopefully the changes were worth that.
>
> Likely broke a lot of distribution setups how?
Previously they could set CPU x and it would still run on other CPUs
even if that option was not set. If that's not the case anymore then
they will have some unhappy users once they update their kernels.
-Andi
--
ak@linux.intel.com
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 15:43 ` H. Peter Anvin
2008-09-08 15:50 ` H. Peter Anvin
2008-09-08 15:50 ` Andi Kleen
@ 2008-09-08 16:07 ` Linus Torvalds
2008-09-08 16:13 ` H. Peter Anvin
2 siblings, 1 reply; 61+ messages in thread
From: Linus Torvalds @ 2008-09-08 16:07 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
On Mon, 8 Sep 2008, H. Peter Anvin wrote:
>
> The help text is indeed out of date. I did a patch yesterday to, among other
> things, update it; I also want to verify that we are disabling all options
> that can cause gcc or binutils to generate nopl's; I plan to push it today.
Peter.
The help text may be out of date because of changes to NOPL usage, but you
should ask yourself whether the change is actually a _good_ change.
IOW, I really don't see why you are pushing changing the help-text,
instead of just making the kernel work better.
The fact that some broken gcc/binutils versions may screw us over _anyway_
may well mean that we should just push back on _that_ change instead.
Quite frankly, from a user perspective, even a very _technical_ one,
please tell me what the advantage of not being fairly generic by default
is. Really.
Yes, there are some _big_ ISA issues where it is worth doing real static
code selection (as opposed to just instruction selection and scheduling
etc that still _works_ for everybody, but optimizes for certain
archtiectures).
So things like cmpxchg/xadd (for atomics) and cmov (for compiler-generated
code), and bswap (for networking) can really make a big difference, and
are not really realistic to do dynamically.
But NOPL? That's simply not _worth_ it being painful over.
And the fact is, the current help text describes
(a) the historical meaning (optimize for a specific architecture, but
don't make extreme choices that are bad for others)
(b) what people would generally _want_.
and I really don't think that changing the help text is the right solution
here. It may be "technically correct", but it is simply not user-friendly
or smart.
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:07 ` Linus Torvalds
@ 2008-09-08 16:13 ` H. Peter Anvin
2008-09-08 16:15 ` H. Peter Anvin
2008-09-08 16:20 ` Linus Torvalds
0 siblings, 2 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 16:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
Linus Torvalds wrote:
>
> and I really don't think that changing the help text is the right solution
> here. It may be "technically correct", but it is simply not user-friendly
> or smart.
>
The issue at hand is that at least with the current toolchain, we need
to pass -march=generic in order for these instructions to be generated.
We have an option for this, CONFIG_X86_GENERIC, which distributions
really *should* be using anyway.
And yes, it should be the default. The patch I have makes it
"default y" as well as change the help text.
Would it make you happier if this option was forced enabled unless
CONFIG_EMBEDDED was on?
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:13 ` H. Peter Anvin
@ 2008-09-08 16:15 ` H. Peter Anvin
2008-09-08 16:26 ` David Sanders
2008-09-08 16:20 ` Linus Torvalds
1 sibling, 1 reply; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 16:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
H. Peter Anvin wrote:
>
> The issue at hand is that at least with the current toolchain, we need
> to pass -march=generic in order for these instructions to be generated.
> We have an option for this, CONFIG_X86_GENERIC, which distributions
> really *should* be using anyway.
>
That should have been "-mtune=generic". Sorry.
> And yes, it should be the default. The patch I have makes it
> "default y" as well as change the help text.
>
> Would it make you happier if this option was forced enabled unless
> CONFIG_EMBEDDED was on?
I guess the other option is to create a new option for selecting the
dangerous -mtune= variants, and possibly lock *that* option to
CONFIG_EMBEDDED.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:13 ` H. Peter Anvin
2008-09-08 16:15 ` H. Peter Anvin
@ 2008-09-08 16:20 ` Linus Torvalds
2008-09-08 16:32 ` H. Peter Anvin
` (2 more replies)
1 sibling, 3 replies; 61+ messages in thread
From: Linus Torvalds @ 2008-09-08 16:20 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
On Mon, 8 Sep 2008, H. Peter Anvin wrote:
>
> And yes, it should be the default. The patch I have makes it
> "default y" as well as change the help text.
It sounds like it shouldn't be a default at all, it should just _always_
be on, if there really are gcc's that care that much. Most of our
optimizations have historically really been about _optimizing_, not about
"it won't work", even if we have had exceptions (but as mentioned, I think
those exceptions have been way more imporant than NOPL).
> Would it make you happier if this option was forced enabled unless
> CONFIG_EMBEDDED was on?
Yes, putting it behind EMBEDDED will certainly fix the issue. Anybody who
actually enables EMBEDDED and does all his choices by hand should no
longer expect to not have to know _exactly_ what he is doing.
So if it's behind EMBEDDED, and defaults to "on", then I have no problem
with changing the help text to say "If you do this, we'll statically do
things that really _require_ you to have a CPU that looks _exactly_ like
the CPU you claimed".
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:15 ` H. Peter Anvin
@ 2008-09-08 16:26 ` David Sanders
0 siblings, 0 replies; 61+ messages in thread
From: David Sanders @ 2008-09-08 16:26 UTC (permalink / raw)
To: linux-kernel
Cc: H. Peter Anvin, Linus Torvalds, Andi Kleen,
the arch/x86 maintainers, Andi Kleen
On Monday 08 September 2008 12:15, H. Peter Anvin wrote:
> H. Peter Anvin wrote:
> > The issue at hand is that at least with the current toolchain, we need
> > to pass -march=generic in order for these instructions to be generated.
> > We have an option for this, CONFIG_X86_GENERIC, which distributions
> > really *should* be using anyway.
>
> That should have been "-mtune=generic". Sorry.
>
> > And yes, it should be the default. The patch I have makes it
> > "default y" as well as change the help text.
> >
> > Would it make you happier if this option was forced enabled unless
> > CONFIG_EMBEDDED was on?
>
> I guess the other option is to create a new option for selecting the
> dangerous -mtune= variants, and possibly lock *that* option to
> CONFIG_EMBEDDED.
>
> -hpa
The option that works best for users is for the kernel to not use NOPLs on
32-bit cpu's. That is what Linus's patch accomplishes. I am not having any
issues with gcc or gas generating NOPLs. The kernel should work out of the
box for PentiumPro or later cpu's running in 32-bit mode. I think you are
trying to over-engineer the issue. Just apply the patch and move on.
David
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:20 ` Linus Torvalds
@ 2008-09-08 16:32 ` H. Peter Anvin
2008-09-08 17:02 ` Ingo Molnar
2008-09-08 16:34 ` david
2008-09-08 17:00 ` Andi Kleen
2 siblings, 1 reply; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 16:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
Linus Torvalds wrote:
>
> So if it's behind EMBEDDED, and defaults to "on", then I have no problem
> with changing the help text to say "If you do this, we'll statically do
> things that really _require_ you to have a CPU that looks _exactly_ like
> the CPU you claimed".
>
Sounds like a plan. I'll have a patch shortly.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:20 ` Linus Torvalds
2008-09-08 16:32 ` H. Peter Anvin
@ 2008-09-08 16:34 ` david
2008-09-08 16:42 ` H. Peter Anvin
2008-09-08 16:59 ` Linus Torvalds
2008-09-08 17:00 ` Andi Kleen
2 siblings, 2 replies; 61+ messages in thread
From: david @ 2008-09-08 16:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Andi Kleen, linux, linux-kernel,
the arch/x86 maintainers, Andi Kleen
On Mon, 8 Sep 2008, Linus Torvalds wrote:
> On Mon, 8 Sep 2008, H. Peter Anvin wrote:
>>
>> And yes, it should be the default. The patch I have makes it
>> "default y" as well as change the help text.
>
> It sounds like it shouldn't be a default at all, it should just _always_
> be on, if there really are gcc's that care that much. Most of our
> optimizations have historically really been about _optimizing_, not about
> "it won't work", even if we have had exceptions (but as mentioned, I think
> those exceptions have been way more imporant than NOPL).
>
>> Would it make you happier if this option was forced enabled unless
>> CONFIG_EMBEDDED was on?
>
> Yes, putting it behind EMBEDDED will certainly fix the issue. Anybody who
> actually enables EMBEDDED and does all his choices by hand should no
> longer expect to not have to know _exactly_ what he is doing.
>
> So if it's behind EMBEDDED, and defaults to "on", then I have no problem
> with changing the help text to say "If you do this, we'll statically do
> things that really _require_ you to have a CPU that looks _exactly_ like
> the CPU you claimed".
I always understood the CPU selection to be "this CPU and ones compatible
with it will work, others won't" unless generic was enabled. the fact that
only a few CPU's wouldn't work and the rest was optimization is true, but
the details of what chips would and wouldn't work were never that clear.
The difference between a kernel compiled for generic and once compiled for
a specific CPU can be very significant. (I ran into 30% differences back
in the 2.4 days between generic and Athlon) This is why all the distros
don't enable the generic cpu option on their kernels nowdays. I'd hate to
see all the distros enabling embedded just to get this performance boost
David Lang
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:34 ` david
@ 2008-09-08 16:42 ` H. Peter Anvin
2008-09-08 18:51 ` david
2008-09-08 16:59 ` Linus Torvalds
1 sibling, 1 reply; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 16:42 UTC (permalink / raw)
To: david
Cc: Linus Torvalds, Andi Kleen, linux, linux-kernel,
the arch/x86 maintainers, Andi Kleen
david@lang.hm wrote:
> I'd hate to see all the distros enabling
> embedded just to get this performance boost
It's about producing code that works generically, not a performance boost.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:34 ` david
2008-09-08 16:42 ` H. Peter Anvin
@ 2008-09-08 16:59 ` Linus Torvalds
1 sibling, 0 replies; 61+ messages in thread
From: Linus Torvalds @ 2008-09-08 16:59 UTC (permalink / raw)
To: david
Cc: H. Peter Anvin, Andi Kleen, linux, linux-kernel,
the arch/x86 maintainers, Andi Kleen
On Mon, 8 Sep 2008, david@lang.hm wrote:
>
> I always understood the CPU selection to be "this CPU and ones compatible with
> it will work, others won't" unless generic was enabled.
No.
Read the help text..
Yes, we care about features that MATTER. But if compiles start using
features that don't really matter, and make a specific kernel _too_
specific, then we need to reign in the madness.
IOW, it's a balance. On one hand, yes, the uarch makes sense. On the
other, it's just stupid to have to worry about details that don't
realistically make any difference at all - except whether the machine
works or not.
And yes, we could just put this up as a Virtual PC bug. It clearly is. But
in the end, it _still_ all boils down to a balance between "do we actually
win anything by using NOPL statically" vs "do we lose anything by being
too damn inconvenient".
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:20 ` Linus Torvalds
2008-09-08 16:32 ` H. Peter Anvin
2008-09-08 16:34 ` david
@ 2008-09-08 17:00 ` Andi Kleen
2008-09-08 17:04 ` Linus Torvalds
2 siblings, 1 reply; 61+ messages in thread
From: Andi Kleen @ 2008-09-08 17:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Andi Kleen, linux, linux-kernel,
the arch/x86 maintainers, Andi Kleen
On Mon, Sep 08, 2008 at 09:20:06AM -0700, Linus Torvalds wrote:
>
>
> On Mon, 8 Sep 2008, H. Peter Anvin wrote:
> >
> > And yes, it should be the default. The patch I have makes it
> > "default y" as well as change the help text.
>
> It sounds like it shouldn't be a default at all, it should just _always_
> be on, if there really are gcc's that care that much. Most of our
Originally it was an option because the 128 byte cache line it selects
caused bloat in several important data structures. That was back
then when cache line padded NR_CPUs arrays were still pretty common.
I don't know if it's still a problem, but before making it default y
it would be good to check the dynamic+static memory cost at least.
-Andi
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:32 ` H. Peter Anvin
@ 2008-09-08 17:02 ` Ingo Molnar
0 siblings, 0 replies; 61+ messages in thread
From: Ingo Molnar @ 2008-09-08 17:02 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Andi Kleen, linux, linux-kernel,
the arch/x86 maintainers, Andi Kleen
* H. Peter Anvin <hpa@zytor.com> wrote:
> Linus Torvalds wrote:
>>
>> So if it's behind EMBEDDED, and defaults to "on", then I have no
>> problem with changing the help text to say "If you do this, we'll
>> statically do things that really _require_ you to have a CPU that
>> looks _exactly_ like the CPU you claimed".
>
> Sounds like a plan. I'll have a patch shortly.
yep. I thought about changing the name and adding a default y but
keeping the name and also putting it behind EMBEDDED would be perfect.
Ingo
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 17:00 ` Andi Kleen
@ 2008-09-08 17:04 ` Linus Torvalds
2008-09-08 17:08 ` H. Peter Anvin
2008-09-08 17:18 ` Andi Kleen
0 siblings, 2 replies; 61+ messages in thread
From: Linus Torvalds @ 2008-09-08 17:04 UTC (permalink / raw)
To: Andi Kleen
Cc: H. Peter Anvin, linux, linux-kernel, the arch/x86 maintainers,
Andi Kleen
On Mon, 8 Sep 2008, Andi Kleen wrote:
>
> Originally it was an option because the 128 byte cache line it selects
> caused bloat in several important data structures. That was back
> then when cache line padded NR_CPUs arrays were still pretty common.
> I don't know if it's still a problem, but before making it default y
> it would be good to check the dynamic+static memory cost at least.
Btw, I do think that the whole NOPL issue is separate from all the other
issues. There can be _other_ cases where it really is worth doing some
"generic" optimizations or being more "specific", and my argument really
is that NOPL is _not_ one of those cases.
So I'm still not sure that X86_GENERIC is necessarily the answer. The
answer may be:
- never use NOPL statically unless we _know_ it works (eg x86-64)
- never allow such a stupid decision by gcc as to use NOPL on x86-32.
..and then leave X86_GENERIC alone wrt everything else.
Peter - does gcc actually use NOPL in _32-bit_ code too? It really seems
to be a stupid decision to make a binary not run on other CPU's over
something as trivial as that. That's something I'd expect out of an Intel
compiler just to mess with AMD, not out of gcc.
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 17:04 ` Linus Torvalds
@ 2008-09-08 17:08 ` H. Peter Anvin
2008-09-08 17:12 ` H. Peter Anvin
2008-09-08 17:38 ` Linus Torvalds
2008-09-08 17:18 ` Andi Kleen
1 sibling, 2 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 17:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
Linus Torvalds wrote:
>
> Peter - does gcc actually use NOPL in _32-bit_ code too? It really seems
> to be a stupid decision to make a binary not run on other CPU's over
> something as trivial as that. That's something I'd expect out of an Intel
> compiler just to mess with AMD, not out of gcc.
>
Yes, it does:
/* We need to decide which NOP sequence to use for 32bit and
64bit. When -mtune= is used:
1. For PROCESSOR_I386, PROCESSOR_I486, PROCESSOR_PENTIUM and
PROCESSOR_GENERIC32, f32_patt will be used.
2. For PROCESSOR_PENTIUMPRO, PROCESSOR_PENTIUM4, PROCESSOR_NOCONA,
PROCESSOR_CORE, PROCESSOR_CORE2, and PROCESSOR_GENERIC64,
alt_long_patt will be used.
3. For PROCESSOR_ATHLON, PROCESSOR_K6, PROCESSOR_K8 and
PROCESSOR_AMDFAM10, alt_short_patt will be used.
When -mtune= isn't used, alt_long_patt will be used if
cpu_arch_isa_flags has Cpu686. Otherwise, f32_patt will
be used.
"alt_long_patt" uses NOPL and its variants.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 17:08 ` H. Peter Anvin
@ 2008-09-08 17:12 ` H. Peter Anvin
2008-09-08 17:41 ` Linus Torvalds
2008-09-08 17:38 ` Linus Torvalds
1 sibling, 1 reply; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 17:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
H. Peter Anvin wrote:
>
> Yes, it does:
>
> /* We need to decide which NOP sequence to use for 32bit and
> 64bit. When -mtune= is used:
>
> 1. For PROCESSOR_I386, PROCESSOR_I486, PROCESSOR_PENTIUM and
> PROCESSOR_GENERIC32, f32_patt will be used.
> 2. For PROCESSOR_PENTIUMPRO, PROCESSOR_PENTIUM4, PROCESSOR_NOCONA,
> PROCESSOR_CORE, PROCESSOR_CORE2, and PROCESSOR_GENERIC64,
> alt_long_patt will be used.
> 3. For PROCESSOR_ATHLON, PROCESSOR_K6, PROCESSOR_K8 and
> PROCESSOR_AMDFAM10, alt_short_patt will be used.
>
> When -mtune= isn't used, alt_long_patt will be used if
> cpu_arch_isa_flags has Cpu686. Otherwise, f32_patt will
> be used.
>
> "alt_long_patt" uses NOPL and its variants.
>
I should point out that the code above is from binutils (gas), not from
gcc. It is entirely possible that doing something like
"-mtune=core2 -Wa,-mtune=generic" might actually work, but I have not
dug through the gcc code proper to figure out if that (a) would work,
and (b) will remain the case...
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 17:04 ` Linus Torvalds
2008-09-08 17:08 ` H. Peter Anvin
@ 2008-09-08 17:18 ` Andi Kleen
1 sibling, 0 replies; 61+ messages in thread
From: Andi Kleen @ 2008-09-08 17:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, H. Peter Anvin, linux, linux-kernel,
the arch/x86 maintainers, Andi Kleen
> Btw, I do think that the whole NOPL issue is separate from all the other
> issues. There can be _other_ cases where it really is worth doing some
> "generic" optimizations or being more "specific", and my argument really
> is that NOPL is _not_ one of those cases.
>
> So I'm still not sure that X86_GENERIC is necessarily the answer. The
FWIW I personally think Linux should always use very conservative nops.
Unconditionally. This issue already cost far too much developer time
and it's unlikely to be worth it.
> Peter - does gcc actually use NOPL in _32-bit_ code too? It really seems
gcc just uses .p2align, so it comes down to binutils
Yes there seems to be a pretty scary ISA selection code in there.
Line 565 of
http://www.google.com/codesearch?hl=en&q=i386_align_code+show:pxieOi43ptA:OXGjJbna8V8:zfd_fdPYgEI&sa=N&cd=1&ct=rc&cs_p=http://gentoo.osuosl.org/distfiles/binutils-2.17.50.0.13.tar.bz2&cs_f=binutils-2.17.50.0.13/gas/config/tc-i386.c
I haven't decoded it completely, but I suspect it does the wrong thing.
-Andi
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 17:08 ` H. Peter Anvin
2008-09-08 17:12 ` H. Peter Anvin
@ 2008-09-08 17:38 ` Linus Torvalds
2008-09-08 17:59 ` H. Peter Anvin
2008-09-08 19:09 ` H. Peter Anvin
1 sibling, 2 replies; 61+ messages in thread
From: Linus Torvalds @ 2008-09-08 17:38 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
On Mon, 8 Sep 2008, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> >
> > Peter - does gcc actually use NOPL in _32-bit_ code too? It really seems to
> > be a stupid decision to make a binary not run on other CPU's over something
> > as trivial as that. That's something I'd expect out of an Intel compiler
> > just to mess with AMD, not out of gcc.
> >
>
> Yes, it does:
>
> /* We need to decide which NOP sequence to use for 32bit and
> 64bit. When -mtune= is used:
>
> 1. For PROCESSOR_I386, PROCESSOR_I486, PROCESSOR_PENTIUM and
> PROCESSOR_GENERIC32, f32_patt will be used.
> 2. For PROCESSOR_PENTIUMPRO, PROCESSOR_PENTIUM4, PROCESSOR_NOCONA,
> PROCESSOR_CORE, PROCESSOR_CORE2, and PROCESSOR_GENERIC64,
> alt_long_patt will be used.
> 3. For PROCESSOR_ATHLON, PROCESSOR_K6, PROCESSOR_K8 and
> PROCESSOR_AMDFAM10, alt_short_patt will be used.
>
> When -mtune= isn't used, alt_long_patt will be used if
> cpu_arch_isa_flags has Cpu686. Otherwise, f32_patt will
> be used.
>
> "alt_long_patt" uses NOPL and its variants.
That is A TOTAL PIECE OF SH*T, and against gcc's own documentation.
"-mtune=x" is very much defined to be a performance _tuning_ option, not
an "architectural" option.
Quite frankly, this is a gcc bug. Plain and simple.
Look at the gcc man-pages. It very much says:
-mtune=cpu_type
Set only the instruction scheduling parameters for machine type
cpu_type. The instruction set is not changed.
(in various different formats - it says the same things with different
words for different architectures. For example, for 386/x86-64 it
_specifically_ says:
-mtune=cpu-type
Tune to cpu-type everything applicable about the generated code,
except for the ABI and the set of available instructions. The
choices for cpu-type are:
note the "except for the ABI and the set of available instructions".
Qutie frankly, I think this is a *much* bigger bug than any possible
VirtualPC idiocy. It's expressly against the whole idea of "-mtune".
Of course, we do set "-march=i686" too, so maybe the gcc people will claim
that that means "Intel CPU's only". But quite frankly, if they really
claim that, then they are lying pond-scum:
i686
Same as "generic", but when used as "march" option, PentiumPro
instruction set will be used, so the code will run on all i686
family chips.
which any sane x86 person would claim includes all the various clone
manufacturers too. Saying that NOPL is so important that "i686" should
suddenly be Intel-only is dishonest and totally stupid.
IOW, somebody who has a gcc bugzilla login should just create a bug-report
on this. There is no question but that this is a bug, plain and simple.
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 17:12 ` H. Peter Anvin
@ 2008-09-08 17:41 ` Linus Torvalds
0 siblings, 0 replies; 61+ messages in thread
From: Linus Torvalds @ 2008-09-08 17:41 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
On Mon, 8 Sep 2008, H. Peter Anvin wrote:
>
> I should point out that the code above is from binutils (gas), not from gcc.
Doesn't matter. If gcc passes "-mtune=i686" down to gas and thus the end
result doesn't match gcc's own documentation (and whole point of -mtune),
then it's still a gcc bug, even if it may not be a "cc1" bug. The fact
that "cc1" and "gas" are two different phases is pretty much irrelevant.
gcc calls them both.
But sure, if there are separate bugzillas, post it in both.
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 17:38 ` Linus Torvalds
@ 2008-09-08 17:59 ` H. Peter Anvin
2008-09-08 19:09 ` H. Peter Anvin
1 sibling, 0 replies; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 17:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers, Andi Kleen
Linus Torvalds wrote:
>
> That is A TOTAL PIECE OF SH*T, and against gcc's own documentation.
>
> "-mtune=x" is very much defined to be a performance _tuning_ option, not
> an "architectural" option.
>
> Quite frankly, this is a gcc bug. Plain and simple.
>
No argument there.
-hpa
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 16:42 ` H. Peter Anvin
@ 2008-09-08 18:51 ` david
0 siblings, 0 replies; 61+ messages in thread
From: david @ 2008-09-08 18:51 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Andi Kleen, linux, linux-kernel,
the arch/x86 maintainers, Andi Kleen
On Mon, 8 Sep 2008, H. Peter Anvin wrote:
> david@lang.hm wrote:
>> I'd hate to see all the distros enabling embedded just to get this
>> performance boost
>
> It's about producing code that works generically, not a performance boost.
I was arguing against the proposal to enable generic unless someone went
under embedded to disable it.
if that's not what was being proposed, my apologies for misunderstanding.
David Lang
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 17:38 ` Linus Torvalds
2008-09-08 17:59 ` H. Peter Anvin
@ 2008-09-08 19:09 ` H. Peter Anvin
2008-09-08 22:42 ` Linus Torvalds
1 sibling, 1 reply; 61+ messages in thread
From: H. Peter Anvin @ 2008-09-08 19:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers
[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]
Linus Torvalds wrote:
>>>
>> Yes, it does:
>>
>> /* We need to decide which NOP sequence to use for 32bit and
>> 64bit. When -mtune= is used:
>>
>> 1. For PROCESSOR_I386, PROCESSOR_I486, PROCESSOR_PENTIUM and
>> PROCESSOR_GENERIC32, f32_patt will be used.
>> 2. For PROCESSOR_PENTIUMPRO, PROCESSOR_PENTIUM4, PROCESSOR_NOCONA,
>> PROCESSOR_CORE, PROCESSOR_CORE2, and PROCESSOR_GENERIC64,
>> alt_long_patt will be used.
>> 3. For PROCESSOR_ATHLON, PROCESSOR_K6, PROCESSOR_K8 and
>> PROCESSOR_AMDFAM10, alt_short_patt will be used.
>>
>> When -mtune= isn't used, alt_long_patt will be used if
>> cpu_arch_isa_flags has Cpu686. Otherwise, f32_patt will
>> be used.
>>
>> "alt_long_patt" uses NOPL and its variants.
>
> That is A TOTAL PIECE OF SH*T, and against gcc's own documentation.
>
> "-mtune=x" is very much defined to be a performance _tuning_ option, not
> an "architectural" option.
>
> Quite frankly, this is a gcc bug. Plain and simple.
>
OK, digging some more into this garbage...
Apparently the situation isn't quite as dire as it first seems.
At least gcc 4.3.0 doesn't actually pass -mtune= to gas; it just drops
the option on the floor. This means this bug isn't manifest when
calling from gcc (as opposed to invoking as directly.)
However, I would still like to push the following patch to be on the
safe side, ok?
-hpa
[-- Attachment #2: 0002-x86-prevent-binutils-from-being-smart-and-generat.patch --]
[-- Type: text/x-patch, Size: 1346 bytes --]
>From 0fbbf1008e5177677dbdb6292d94ec40df965d82 Mon Sep 17 00:00:00 2001
From: H. Peter Anvin <hpa@zytor.com>
Date: Mon, 8 Sep 2008 12:01:48 -0700
Subject: [PATCH] x86: prevent binutils from being "smart" and generating NOPLs for us
binutils, contrary to documented behaviour, will generate long NOPs (a
P6-or-higher instruction which is broken on at least some VIA chips,
Virtual PC/Virtual Server, and some versions of Qemu) depending on the
-mtune= option, which is not supposed to change architectural
behaviour.
Pass an explicit override to the assembler, in case ends up passing
the -mtune= parameter to gas (gcc 4.3.0 does not appear to.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
---
arch/x86/Makefile_32.cpu | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/x86/Makefile_32.cpu b/arch/x86/Makefile_32.cpu
index e372b58..b72b4f7 100644
--- a/arch/x86/Makefile_32.cpu
+++ b/arch/x86/Makefile_32.cpu
@@ -45,3 +45,8 @@ cflags-$(CONFIG_MGEODEGX1) += -march=pentium-mmx
# cpu entries
cflags-$(CONFIG_X86_GENERIC) += $(call tune,generic,$(call tune,i686))
+# Bug fix for binutils: this option is required in order to keep
+# binutils from generating NOPL instructions against our will.
+ifneq ($(CONFIG_X86_P6_NOP),y)
+cflags-y += $(call cc-option,-Wa$(comma)-mtune=generic32,)
+endif
--
1.5.5.1
^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [BUG] x86 kenel won't boot under Virtual PC
2008-09-08 19:09 ` H. Peter Anvin
@ 2008-09-08 22:42 ` Linus Torvalds
0 siblings, 0 replies; 61+ messages in thread
From: Linus Torvalds @ 2008-09-08 22:42 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Andi Kleen, linux, linux-kernel, the arch/x86 maintainers
On Mon, 8 Sep 2008, H. Peter Anvin wrote:
>
> OK, digging some more into this garbage...
>
> Apparently the situation isn't quite as dire as it first seems.
> At least gcc 4.3.0 doesn't actually pass -mtune= to gas; it just drops the
> option on the floor. This means this bug isn't manifest when calling from gcc
> (as opposed to invoking as directly.)
Ok, goodie. And we don't pass the -mtune=xyz option when we use gas
directly, so we should be all ok.
> However, I would still like to push the following patch to be on the safe
> side, ok?
I have no problem with it, with the fix to actually assemble things. But I
also don't think it's a huge deal (ie not 2.6.27 stuff - we don't know
if some odd version of as does something odd with -mtune=generic, or
whether this can interact oddly with some version of gcc perhaps passing
the _correct_ -mtune to the assembler?).
Linus
^ permalink raw reply [flat|nested] 61+ messages in thread
end of thread, other threads:[~2008-09-08 22:42 UTC | newest]
Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-08-31 18:22 [BUG] x86 kenel won't boot under Virtual PC David Sanders
2008-08-31 18:47 ` Linus Torvalds
2008-08-31 19:27 ` Arjan van de Ven
2008-08-31 19:39 ` Linus Torvalds
2008-09-05 15:38 ` David Sanders
2008-09-05 16:15 ` Jan Beulich
2008-09-05 16:39 ` Linus Torvalds
2008-09-05 18:43 ` Ingo Molnar
2008-09-05 20:06 ` H. Peter Anvin
2008-09-05 19:08 ` Jeremy Fitzhardinge
2008-09-05 20:12 ` H. Peter Anvin
2008-09-05 16:30 ` Linus Torvalds
2008-09-05 17:55 ` Andi Kleen
2008-08-31 20:03 ` David Sanders
2008-09-01 20:23 ` David Sanders
2008-09-01 22:22 ` Linus Torvalds
2008-09-02 12:08 ` David Sanders
2008-09-02 18:12 ` Linus Torvalds
2008-09-02 18:44 ` David Sanders
2008-09-03 11:09 ` Peter Zijlstra
2008-09-03 11:20 ` David Sanders
[not found] ` <48C1C156.9080003@zytor.com>
2008-09-07 20:07 ` David Sanders
2008-09-07 23:22 ` David Sanders
2008-09-08 1:48 ` H. Peter Anvin
2008-09-08 2:49 ` David Sanders
2008-09-08 4:04 ` H. Peter Anvin
2008-09-08 9:42 ` Andi Kleen
2008-09-08 13:25 ` David Sanders
2008-09-08 15:09 ` Linus Torvalds
2008-09-08 15:23 ` Ingo Molnar
2008-09-08 15:36 ` H. Peter Anvin
2008-09-08 15:38 ` David Sanders
2008-09-08 15:38 ` H. Peter Anvin
2008-09-08 15:45 ` Andi Kleen
2008-09-08 15:43 ` H. Peter Anvin
2008-09-08 15:50 ` H. Peter Anvin
2008-09-08 15:50 ` Andi Kleen
2008-09-08 15:50 ` H. Peter Anvin
2008-09-08 15:57 ` Andi Kleen
2008-09-08 15:54 ` H. Peter Anvin
2008-09-08 16:07 ` Linus Torvalds
2008-09-08 16:13 ` H. Peter Anvin
2008-09-08 16:15 ` H. Peter Anvin
2008-09-08 16:26 ` David Sanders
2008-09-08 16:20 ` Linus Torvalds
2008-09-08 16:32 ` H. Peter Anvin
2008-09-08 17:02 ` Ingo Molnar
2008-09-08 16:34 ` david
2008-09-08 16:42 ` H. Peter Anvin
2008-09-08 18:51 ` david
2008-09-08 16:59 ` Linus Torvalds
2008-09-08 17:00 ` Andi Kleen
2008-09-08 17:04 ` Linus Torvalds
2008-09-08 17:08 ` H. Peter Anvin
2008-09-08 17:12 ` H. Peter Anvin
2008-09-08 17:41 ` Linus Torvalds
2008-09-08 17:38 ` Linus Torvalds
2008-09-08 17:59 ` H. Peter Anvin
2008-09-08 19:09 ` H. Peter Anvin
2008-09-08 22:42 ` Linus Torvalds
2008-09-08 17:18 ` Andi Kleen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).