x86, alternatives: Use 16-bit numbers for cpufeature index [Kernel]

Prev: Btrfs: broken file system design
Next: pcf857x: support working w/o platform data

From: Lai Jiangshan on 25 Jun 2010 05:30

tip-bot for H. Peter Anvin wrote:
> Commit-ID: f88731e3068f9d1392ba71cc9f50f035d26a0d4f
> Gitweb: http://git.kernel.org/tip/f88731e3068f9d1392ba71cc9f50f035d26a0d4f
> Author: H. Peter Anvin <hpa(a)linux.intel.com>
> AuthorDate: Wed, 9 Jun 2010 16:03:09 -0700
> Committer: H. Peter Anvin <hpa(a)linux.intel.com>
> CommitDate: Wed, 9 Jun 2010 16:03:09 -0700
>
> x86, alternatives: Use 16-bit numbers for cpufeature index
>
> We already have cpufeature indicies above 255, so use a 16-bit number
> for the alternatives index. This consumes a padding field and so
> doesn't add any size, but it means that abusing the padding field to
> create assembly errors on overflow no longer works. We can retain the
> test simply by redirecting it to the .discard section, however.
>

My machine hits "invalid opcode" at *prepare_to_copy+0x79,
and it can't boot up.

(gdb) l *prepare_to_copy+0x79
0xc0101789 is in prepare_to_copy (/home/njubee/work/linux-2.6-tip/arch/x86/include/asm/xsave.h:118).
113
114 static inline void fpu_xsave(struct fpu *fpu)
115 {
116 /* This, however, we can work around by forcing the compiler to select
117 an addressing mode that doesn't require extended registers. */
118 __asm__ __volatile__(".byte " REX_PREFIX "0x0f,0xae,0x27"
119 : : "D" (&(fpu->state->xsave)),
120 "a" (-1), "d"(-1) : "memory");
121 }
122 #endif

It can boot up if this patch is reverted.
Does this patch change the return value of "use_xsave()"

cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) D CPU 2.80GHz
stepping : 8
cpu MHz : 2800.120
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss constant_tsc pebs bts tsc_reliable pni ds_cpl
bogomips : 5600.24
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) D CPU 2.80GHz
stepping : 8
cpu MHz : 2800.120
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss constant_tsc pebs bts tsc_reliable pni ds_cpl
bogomips : 5574.36
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: H. Peter Anvin on 25 Jun 2010 11:40

On 06/25/2010 02:20 AM, Lai Jiangshan wrote:
>>
>> x86, alternatives: Use 16-bit numbers for cpufeature index
>>
>> We already have cpufeature indicies above 255, so use a 16-bit number
>> for the alternatives index. This consumes a padding field and so
>> doesn't add any size, but it means that abusing the padding field to
>> create assembly errors on overflow no longer works. We can retain the
>> test simply by redirecting it to the .discard section, however.
>>
>
> My machine hits "invalid opcode" at *prepare_to_copy+0x79,
> and it can't boot up.
>
> (gdb) l *prepare_to_copy+0x79
> 0xc0101789 is in prepare_to_copy (/home/njubee/work/linux-2.6-tip/arch/x86/include/asm/xsave.h:118).
> 113
> 114 static inline void fpu_xsave(struct fpu *fpu)
> 115 {
> 116 /* This, however, we can work around by forcing the compiler to select
> 117 an addressing mode that doesn't require extended registers. */
> 118 __asm__ __volatile__(".byte " REX_PREFIX "0x0f,0xae,0x27"
> 119 : : "D" (&(fpu->state->xsave)),
> 120 "a" (-1), "d"(-1) : "memory");
> 121 }
> 122 #endif
>

There are no alternatives in that code, at all... so it makes me really
wonder what is going on. One possibility, of course, is that one
alternative has ended up with the wrong address. Will look...

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: Lai Jiangshan on 28 Jun 2010 04:00

H. Peter Anvin wrote:
> On 06/25/2010 02:20 AM, Lai Jiangshan wrote:
>>> x86, alternatives: Use 16-bit numbers for cpufeature index
>>>
>>> We already have cpufeature indicies above 255, so use a 16-bit number
>>> for the alternatives index. This consumes a padding field and so
>>> doesn't add any size, but it means that abusing the padding field to
>>> create assembly errors on overflow no longer works. We can retain the
>>> test simply by redirecting it to the .discard section, however.
>>>
>> My machine hits "invalid opcode" at *prepare_to_copy+0x79,
>> and it can't boot up.
>>
>> (gdb) l *prepare_to_copy+0x79
>> 0xc0101789 is in prepare_to_copy (/home/njubee/work/linux-2.6-tip/arch/x86/include/asm/xsave.h:118).
>> 113
>> 114 static inline void fpu_xsave(struct fpu *fpu)
>> 115 {
>> 116 /* This, however, we can work around by forcing the compiler to select
>> 117 an addressing mode that doesn't require extended registers. */
>> 118 __asm__ __volatile__(".byte " REX_PREFIX "0x0f,0xae,0x27"
>> 119 : : "D" (&(fpu->state->xsave)),
>> 120 "a" (-1), "d"(-1) : "memory");
>> 121 }
>> 122 #endif
>>
>
> There are no alternatives in that code, at all... so it makes me really
> wonder what is going on. One possibility, of course, is that one
> alternative has ended up with the wrong address. Will look...
>

There is alternative in use_xsave().
use_xsave() should return false in my system, but it returns true after this patch applied.

>> Does this patch change the return value of "use_xsave()"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: H. Peter Anvin on 28 Jun 2010 15:00

On 06/28/2010 12:58 AM, Lai Jiangshan wrote:
>
> There is alternative in use_xsave().
> use_xsave() should return false in my system, but it returns true after this patch applied.
>

OK, so a false substitution... strange.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

From: H. Peter Anvin on 28 Jun 2010 15:10

| Next | Last
Pages: 1 2
Prev: Btrfs: broken file system design
Next: pcf857x: support working w/o platform data