Skip to contentSkip to conversation

fix x86 cpuid keys used in alternative_smp()

PATCH In review Jan Beulich 2 participants 3 messages Aug 15, 2006 – Aug 16, 2006

lore
Share & tools
lore

Jan Beulich

author
#0 lore raw

PATCH 1/1 fix x86 cpuid keys used in alternative_smp()

By hard-coding the cpuid keys for alternative_smp() rather than using the symbolic constant it turned out that incorrect values were used on both i386 (0x68 instead of 0x69) and x86-64 (0x66 instead of 0x68).

Signed-off-by Jan Beulich <[email protected]>
include/asm-i386/alternative.h +1 -1
@@ -116,7 +116,7 @@ static inline void alternatives_smp_swit
 		      "  .align 4\n"					\
 		      "  .long 661b\n"            /* label */		\
 		      "  .long 663f\n"		  /* new instruction */	\
-		      "  .byte 0x68\n"            /* X86_FEATURE_UP */	\
+		      "  .byte " __stringify(X86_FEATURE_UP) "\n"	\
 		      "  .byte 662b-661b\n"       /* sourcelen */	\
 		      "  .byte 664f-663f\n"       /* replacementlen */	\
 		      ".previous\n"					\
include/asm-x86_64/alternative.h +1 -1
@@ -130,7 +130,7 @@ static inline void alternatives_smp_swit
 		      "  .align 8\n"					\
 		      "  .quad 661b\n"            /* label */		\
 		      "  .quad 663f\n"		  /* new instruction */	\
-		      "  .byte 0x66\n"            /* X86_FEATURE_UP */	\
+		      "  .byte " __stringify(X86_FEATURE_UP) "\n"	\
 		      "  .byte 662b-661b\n"       /* sourcelen */	\
 		      "  .byte 664f-663f\n"       /* replacementlen */	\
 		      ".previous\n"					\
#1 lore raw
Quoted 3 lines · On Tue, 15 Aug 2006 18:03:08 +0200 "Jan Beulich" <[email protected]> wrote:

By hard-coding the cpuid keys for alternative_smp() rather than using the symbolic constant it turned out that incorrect values were used on both i386 (0x68 instead of 0x69) and x86-64 (0x66 instead of 0x68).

Thanks. Applied.

I wonder if that was the reason why the .fill misassembly the 2.16.91.0.5 (10.1) binutils commits (see recent discuss report from Rafael) didn't cause crashes on UP machines. Do you have an opinion on that?

-Andi
]

author
#2 lore raw
Quoted 10 lines
Quoted 3 lines

By hard-coding the cpuid keys for alternative_smp() rather than using the symbolic constant it turned out that incorrect values were used on both i386 (0x68 instead of 0x69) and x86-64 (0x66 instead of 0x68).

Thanks. Applied.

I wonder if that was the reason why the .fill misassembly the 2.16.91.0.5 (10.1) binutils commits (see recent discuss report from Rafael) didn't cause crashes on UP machines. Do you have an opinion on that?

That is well possible - I saw the mail, and I also wondered why this wouldn't result in a broken kernel.

Jan