Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-21 Thread H. Peter Anvin
On 07/20/2013 05:25 AM, George Spelvin wrote:
> It's marginal with only two call sites, but would it be worth factoring
> out the write-back function?  Something like this (untested) patch.
> It definitely makes the generated assembly cleaner.
> 
> (Signed-off-by: George Spelvin  if you want it.)

Two call sites, statistically "never" executed, really doesn't justify
adding a new assembly function.  I was considering making a C wrapper,
though... I would also like to change these to using rdmsrl/wrmsrl.

-hpa


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


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-21 Thread H. Peter Anvin
On 07/20/2013 05:25 AM, George Spelvin wrote:
 It's marginal with only two call sites, but would it be worth factoring
 out the write-back function?  Something like this (untested) patch.
 It definitely makes the generated assembly cleaner.
 
 (Signed-off-by: George Spelvin li...@horizon.com if you want it.)

Two call sites, statistically never executed, really doesn't justify
adding a new assembly function.  I was considering making a C wrapper,
though... I would also like to change these to using rdmsrl/wrmsrl.

-hpa


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


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-20 Thread Borislav Petkov
On Sat, Jul 20, 2013 at 10:47:58AM -0400, George Spelvin wrote:
> Borislav Petkov  wrote:
> > I don't think that matters because this is called only once on suspend.
> > Unless the cleaner assembly translates into a palpable speedup, which I
> > doubt.
> 
> I was thinking about code *size*, actually; I agree that speed is
> too small to measure.
> 
> Clean code (21 bytes):
>   4e:   b9 80 00 00 c0  mov$0xc080,%ecx
>   53:   0f 32   rdmsr  
>   55:   0f 30   wrmsr  
>   57:   31 f6   xor%esi,%esi
>   59:   85 f6   test   %esi,%esi
>   5b:   89 43 14mov%eax,0x14(%ebx)
>   5e:   89 53 18mov%edx,0x18(%ebx)
>   61:   75 04   jne67 
> 
> Ugly code (50 bytes):

Right, that would matter maybe partially if the code was executed very
often. In that case, the probability of it fitting in one cacheline is
higher depending on alignment, and, you'd possibly save yourself loading
a second cacheline.

If it is 29 bytes bigger, than we have a higher probability for using a
second cacheline.

But again, I highly doubt even that would be noticeable. Especially on
modern uarches with very aggressive and smart branch prediction.

And since this is being called only once, you won't notice the
difference even with perf and specific instruction cache counters
enabled.

But what do I know - I'm always open to surprising workloads! :-)

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-20 Thread George Spelvin
Borislav Petkov  wrote:
> I don't think that matters because this is called only once on suspend.
> Unless the cleaner assembly translates into a palpable speedup, which I
> doubt.

I was thinking about code *size*, actually; I agree that speed is
too small to measure.

Clean code (21 bytes):
  4e:   b9 80 00 00 c0  mov$0xc080,%ecx
  53:   0f 32   rdmsr  
  55:   0f 30   wrmsr  
  57:   31 f6   xor%esi,%esi
  59:   85 f6   test   %esi,%esi
  5b:   89 43 14mov%eax,0x14(%ebx)
  5e:   89 53 18mov%edx,0x18(%ebx)
  61:   75 04   jne67 

Ugly code (50 bytes):
  51:   b9 80 00 00 c0  mov$0xc080,%ecx
  56:   0f 32   rdmsr  
  58:   31 c9   xor%ecx,%ecx
  5a:   89 c6   mov%eax,%esi
  5c:   85 c9   test   %ecx,%ecx
  5e:   89 45 ecmov%eax,-0x14(%ebp)
  61:   89 55 f0mov%edx,-0x10(%ebp)
  64:   89 73 14mov%esi,0x14(%ebx)
  67:   89 53 18mov%edx,0x18(%ebx)
  6a:   75 1b   jne87 
  6c:   8b 75 ecmov-0x14(%ebp),%esi
  6f:   b9 80 00 00 c0  mov$0xc080,%ecx
  74:   8b 7d f0mov-0x10(%ebp),%edi
  77:   89 f0   mov%esi,%eax
  79:   89 fa   mov%edi,%edx
  7b:   0f 30   wrmsr  
  7d:   31 c0   xor%eax,%eax
  7f:   85 c0   test   %eax,%eax
  81:   75 04   jne87 

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


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-20 Thread Borislav Petkov
On Sat, Jul 20, 2013 at 08:25:04AM -0400, George Spelvin wrote:
> It's marginal with only two call sites, but would it be worth factoring
> out the write-back function?  Something like this (untested) patch.
> It definitely makes the generated assembly cleaner.

I don't think that matters because this is called only once on suspend.
Unless the cleaner assembly translates into a palpable speedup, which I
doubt.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-20 Thread George Spelvin
It's marginal with only two call sites, but would it be worth factoring
out the write-back function?  Something like this (untested) patch.
It definitely makes the generated assembly cleaner.

(Signed-off-by: George Spelvin  if you want it.)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index cb75028..8802d97 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -171,6 +171,30 @@ static inline int wrmsr_safe(unsigned msr, unsigned low, 
unsigned high)
__err;  \
 })
 
+/*
+ * We have to check that we can write back the value, and not just
+ * read it.  At least on 90 nm Pentium M (Family 6, Model 13), reading
+ * an invalid MSR is not guaranteed to trap, see Erratum X4 in "Intel
+ * Pentium M Processor on 90 nm Process with 2-MB L2 Cache and Intel®
+ * Processor A100 and A110 on 90 nm process with 512-KB L2 Cache
+ * Specification Update".
+ */
+#define rdmsr_verysafe(msr, low, high) \
+({ \
+   int __err;  \
+   asm volatile("2: rdmsr\n"   \
+"3: wrmsr ; xor %[err],%[err]\n"   \
+"1:\n\t"   \
+".section .fixup,\"ax\"\n\t"   \
+"4:  mov %[fault],%[err] ; jmp 1b\n\t" \
+".previous\n\t"\
+_ASM_EXTABLE(2b, 4b)   \
+_ASM_EXTABLE(3b, 4b)   \
+: [err] "=r" (__err), "=a" (*low), "=d" (*high) \
+: "c" (msr), [fault] "i" (-EIO));  \
+   __err;  \
+})
+
 static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 {
int err;
diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
index b44577b..7c3f40c 100644
--- a/arch/x86/kernel/acpi/sleep.c
+++ b/arch/x86/kernel/acpi/sleep.c
@@ -48,9 +48,9 @@ int acpi_suspend_lowlevel(void)
 #ifndef CONFIG_64BIT
native_store_gdt((struct desc_ptr *)>pmode_gdt);
 
-   if (!rdmsr_safe(MSR_EFER,
-   >pmode_efer_low,
-   >pmode_efer_high))
+   if (!rdmsr_verysafe(MSR_EFER,
+   >pmode_efer_low,
+   >pmode_efer_high))
header->pmode_behavior |= (1 << WAKEUP_BEHAVIOR_RESTORE_EFER);
 #endif /* !CONFIG_64BIT */
 
@@ -59,9 +59,9 @@ int acpi_suspend_lowlevel(void)
header->pmode_cr4 = read_cr4();
header->pmode_behavior |= (1 << WAKEUP_BEHAVIOR_RESTORE_CR4);
}
-   if (!rdmsr_safe(MSR_IA32_MISC_ENABLE,
-   >pmode_misc_en_low,
-   >pmode_misc_en_high))
+   if (!rdmsr_verysafe(MSR_IA32_MISC_ENABLE,
+   >pmode_misc_en_low,
+   >pmode_misc_en_high))
header->pmode_behavior |=
(1 << WAKEUP_BEHAVIOR_RESTORE_MISC_ENABLE);
header->realmode_flags = acpi_realmode_flags;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-20 Thread George Spelvin
It's marginal with only two call sites, but would it be worth factoring
out the write-back function?  Something like this (untested) patch.
It definitely makes the generated assembly cleaner.

(Signed-off-by: George Spelvin li...@horizon.com if you want it.)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index cb75028..8802d97 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -171,6 +171,30 @@ static inline int wrmsr_safe(unsigned msr, unsigned low, 
unsigned high)
__err;  \
 })
 
+/*
+ * We have to check that we can write back the value, and not just
+ * read it.  At least on 90 nm Pentium M (Family 6, Model 13), reading
+ * an invalid MSR is not guaranteed to trap, see Erratum X4 in Intel
+ * Pentium M Processor on 90 nm Process with 2-MB L2 Cache and Intel®
+ * Processor A100 and A110 on 90 nm process with 512-KB L2 Cache
+ * Specification Update.
+ */
+#define rdmsr_verysafe(msr, low, high) \
+({ \
+   int __err;  \
+   asm volatile(2: rdmsr\n   \
+3: wrmsr ; xor %[err],%[err]\n   \
+1:\n\t   \
+.section .fixup,\ax\\n\t   \
+4:  mov %[fault],%[err] ; jmp 1b\n\t \
+.previous\n\t\
+_ASM_EXTABLE(2b, 4b)   \
+_ASM_EXTABLE(3b, 4b)   \
+: [err] =r (__err), =a (*low), =d (*high) \
+: c (msr), [fault] i (-EIO));  \
+   __err;  \
+})
+
 static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 {
int err;
diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
index b44577b..7c3f40c 100644
--- a/arch/x86/kernel/acpi/sleep.c
+++ b/arch/x86/kernel/acpi/sleep.c
@@ -48,9 +48,9 @@ int acpi_suspend_lowlevel(void)
 #ifndef CONFIG_64BIT
native_store_gdt((struct desc_ptr *)header-pmode_gdt);
 
-   if (!rdmsr_safe(MSR_EFER,
-   header-pmode_efer_low,
-   header-pmode_efer_high))
+   if (!rdmsr_verysafe(MSR_EFER,
+   header-pmode_efer_low,
+   header-pmode_efer_high))
header-pmode_behavior |= (1  WAKEUP_BEHAVIOR_RESTORE_EFER);
 #endif /* !CONFIG_64BIT */
 
@@ -59,9 +59,9 @@ int acpi_suspend_lowlevel(void)
header-pmode_cr4 = read_cr4();
header-pmode_behavior |= (1  WAKEUP_BEHAVIOR_RESTORE_CR4);
}
-   if (!rdmsr_safe(MSR_IA32_MISC_ENABLE,
-   header-pmode_misc_en_low,
-   header-pmode_misc_en_high))
+   if (!rdmsr_verysafe(MSR_IA32_MISC_ENABLE,
+   header-pmode_misc_en_low,
+   header-pmode_misc_en_high))
header-pmode_behavior |=
(1  WAKEUP_BEHAVIOR_RESTORE_MISC_ENABLE);
header-realmode_flags = acpi_realmode_flags;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-20 Thread Borislav Petkov
On Sat, Jul 20, 2013 at 08:25:04AM -0400, George Spelvin wrote:
 It's marginal with only two call sites, but would it be worth factoring
 out the write-back function?  Something like this (untested) patch.
 It definitely makes the generated assembly cleaner.

I don't think that matters because this is called only once on suspend.
Unless the cleaner assembly translates into a palpable speedup, which I
doubt.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-20 Thread George Spelvin
Borislav Petkov b...@alien8.de wrote:
 I don't think that matters because this is called only once on suspend.
 Unless the cleaner assembly translates into a palpable speedup, which I
 doubt.

I was thinking about code *size*, actually; I agree that speed is
too small to measure.

Clean code (21 bytes):
  4e:   b9 80 00 00 c0  mov$0xc080,%ecx
  53:   0f 32   rdmsr  
  55:   0f 30   wrmsr  
  57:   31 f6   xor%esi,%esi
  59:   85 f6   test   %esi,%esi
  5b:   89 43 14mov%eax,0x14(%ebx)
  5e:   89 53 18mov%edx,0x18(%ebx)
  61:   75 04   jne67 acpi_suspend_lowlevel+0x67

Ugly code (50 bytes):
  51:   b9 80 00 00 c0  mov$0xc080,%ecx
  56:   0f 32   rdmsr  
  58:   31 c9   xor%ecx,%ecx
  5a:   89 c6   mov%eax,%esi
  5c:   85 c9   test   %ecx,%ecx
  5e:   89 45 ecmov%eax,-0x14(%ebp)
  61:   89 55 f0mov%edx,-0x10(%ebp)
  64:   89 73 14mov%esi,0x14(%ebx)
  67:   89 53 18mov%edx,0x18(%ebx)
  6a:   75 1b   jne87 acpi_suspend_lowlevel+0x87
  6c:   8b 75 ecmov-0x14(%ebp),%esi
  6f:   b9 80 00 00 c0  mov$0xc080,%ecx
  74:   8b 7d f0mov-0x10(%ebp),%edi
  77:   89 f0   mov%esi,%eax
  79:   89 fa   mov%edi,%edx
  7b:   0f 30   wrmsr  
  7d:   31 c0   xor%eax,%eax
  7f:   85 c0   test   %eax,%eax
  81:   75 04   jne87 acpi_suspend_lowlevel+0x87

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


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-20 Thread Borislav Petkov
On Sat, Jul 20, 2013 at 10:47:58AM -0400, George Spelvin wrote:
 Borislav Petkov b...@alien8.de wrote:
  I don't think that matters because this is called only once on suspend.
  Unless the cleaner assembly translates into a palpable speedup, which I
  doubt.
 
 I was thinking about code *size*, actually; I agree that speed is
 too small to measure.
 
 Clean code (21 bytes):
   4e:   b9 80 00 00 c0  mov$0xc080,%ecx
   53:   0f 32   rdmsr  
   55:   0f 30   wrmsr  
   57:   31 f6   xor%esi,%esi
   59:   85 f6   test   %esi,%esi
   5b:   89 43 14mov%eax,0x14(%ebx)
   5e:   89 53 18mov%edx,0x18(%ebx)
   61:   75 04   jne67 acpi_suspend_lowlevel+0x67
 
 Ugly code (50 bytes):

Right, that would matter maybe partially if the code was executed very
often. In that case, the probability of it fitting in one cacheline is
higher depending on alignment, and, you'd possibly save yourself loading
a second cacheline.

If it is 29 bytes bigger, than we have a higher probability for using a
second cacheline.

But again, I highly doubt even that would be noticeable. Especially on
modern uarches with very aggressive and smart branch prediction.

And since this is being called only once, you won't notice the
difference even with perf and specific instruction cache counters
enabled.

But what do I know - I'm always open to surprising workloads! :-)

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [OT] Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-19 Thread H. Peter Anvin
On 07/19/2013 02:38 AM, Geert Uytterhoeven wrote:
> 
> Can we please stop writing these _mixed_ English/Finnish emails?
> 

Nyet.

-hpa

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


Re: [OT] Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-19 Thread Geert Uytterhoeven
On Fri, Jul 19, 2013 at 9:45 AM, Lukasz Sokol  wrote:
> H. Peter Anvin  zytor.com> writes:
>> Ehkä meidän sääntö, että kiroilu on sallittu vain suomeksi (ja venäjä,
>> muuten Al Viro todennäköisesti räjähtää.)

Can we please stop writing these _mixed_ English/Finnish emails?
As Chrome only offers to translate _pure_ Finnish emails, that would save
most of us a copy-and-paste trip to translate.google.com ;-)

> Try pasting that back into Google Translate ;) see what Viro is translated
> to  ;)
>
> -L ;)

Da!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[OT] Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-19 Thread Lukasz Sokol
H. Peter Anvin  zytor.com> writes:
> Ehkä meidän sääntö, että kiroilu on sallittu vain suomeksi (ja venäjä,
> muuten Al Viro todennäköisesti räjähtää.)
> 
>   -hpa

Try pasting that back into Google Translate ;) see what Viro is translated 
to  ;)

-L ;)
--- 
These lines are added to increase my message to your message ratio,
to keep Gmane web interface happy.

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


[OT] Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-19 Thread Lukasz Sokol
H. Peter Anvin hpa at zytor.com writes:
 Ehkä meidän sääntö, että kiroilu on sallittu vain suomeksi (ja venäjä,
 muuten Al Viro todennäköisesti räjähtää.)
 
   -hpa

Try pasting that back into Google Translate ;) see what Viro is translated 
to  ;)

-L ;)
--- 
These lines are added to increase my message to your message ratio,
to keep Gmane web interface happy.

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


Re: [OT] Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-19 Thread Geert Uytterhoeven
On Fri, Jul 19, 2013 at 9:45 AM, Lukasz Sokol el.es...@gmail.com wrote:
 H. Peter Anvin hpa at zytor.com writes:
 Ehkä meidän sääntö, että kiroilu on sallittu vain suomeksi (ja venäjä,
 muuten Al Viro todennäköisesti räjähtää.)

Can we please stop writing these _mixed_ English/Finnish emails?
As Chrome only offers to translate _pure_ Finnish emails, that would save
most of us a copy-and-paste trip to translate.google.com ;-)

 Try pasting that back into Google Translate ;) see what Viro is translated
 to  ;)

 -L ;)

Da!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [OT] Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-19 Thread H. Peter Anvin
On 07/19/2013 02:38 AM, Geert Uytterhoeven wrote:
 
 Can we please stop writing these _mixed_ English/Finnish emails?
 

Nyet.

-hpa

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


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-18 Thread H. Peter Anvin
On 07/18/2013 05:46 PM, Linus Torvalds wrote:
> 
> Finnish is hard. But good for swearing.
> 

Ehkä meidän sääntö, että kiroilu on sallittu vain suomeksi (ja venäjä,
muuten Al Viro todennäköisesti räjähtää.)

-hpa

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


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-18 Thread H. Peter Anvin
On 07/18/2013 05:46 PM, Linus Torvalds wrote:
> 
> Finnish is hard. But good for swearing.
> 

http://www.youtube.com/watch?v=b1fkMuMDqXI

It probably won't make too much sense if you haven't seen:

http://www.youtube.com/watch?v=_4bka9Y2gJ0

-hpa

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


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-18 Thread Myklebust, Trond
On Thu, 2013-07-18 at 17:46 -0700, Linus Torvalds wrote:

> Finnish is hard. But good for swearing.

Only because the ratio of vowels to consonants causes an immediate
outbreak of swearing among those who try...

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
trond.mykleb...@netapp.com
www.netapp.com


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-18 Thread Linus Torvalds
Google translate is getting better. I was going to ask you who you
knew who had enough of a Finnish background to do that, but decided to
see what I could make google translate do.

I'm pretty sure google didn't _use_ to do that good a job at Finnish.
It would be "pääksi", not "pää", but I think you edited that part by
hand without knowing the rules for Finnish translative declension.

Finnish is hard. But good for swearing.

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


[GIT PULL] x86 fixes for 3.11-rc2

2013-07-18 Thread H. Peter Anvin
Hi Linus,

Trying again to get the fixes queue, including the fixed IDT alignment
patch.

The UEFI patch is by far the biggest issue at hand: it is currently
causing quite a few machines to boot.  Which is sad, because the only
reason they would is because their BIOSes touch memory that has
already been freed.  The other major issue is that we finally have
tracked down the root cause of a significant number of machines
failing to suspend/resume.

Toivottavasti sinun ei tarvitse kutsua minua perkeleen vittupää tällä
kertaa.

The following changes since commit 6d128e1e72bf082542e85f72e6b7ddd704193588:

  Revert "Makefile: Fix install error with make -j option" (2013-07-10 19:02:51 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus

for you to fetch changes up to 4df05f361937ee86e5a8c9ead8aeb6a19ea9b7d7:

  x86: Make sure IDT is page aligned (2013-07-16 15:14:48 -0700)


H. Peter Anvin (1):
  x86, suspend: Handle CPUs which fail to #GP on RDMSR

Kees Cook (1):
  x86: Make sure IDT is page aligned

Matt Fleming (2):
  efivars: check for EFI_RUNTIME_SERVICES
  Revert "UEFI: Don't pass boot services regions to SetVirtualAddressMap()"

Xiong Zhou (1):
  x86/platform/ce4100: Add header file for reboot type

 arch/x86/kernel/acpi/sleep.c  | 18 --
 arch/x86/kernel/head_64.S | 15 ---
 arch/x86/kernel/tracepoint.c  |  6 ++
 arch/x86/kernel/traps.c   | 12 ++--
 arch/x86/platform/ce4100/ce4100.c |  1 +
 arch/x86/platform/efi/efi.c   |  7 ---
 drivers/firmware/efi/efivars.c|  3 +++
 7 files changed, 28 insertions(+), 34 deletions(-)

diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
index 2a34aaf..3312010 100644
--- a/arch/x86/kernel/acpi/sleep.c
+++ b/arch/x86/kernel/acpi/sleep.c
@@ -48,9 +48,20 @@ int x86_acpi_suspend_lowlevel(void)
 #ifndef CONFIG_64BIT
native_store_gdt((struct desc_ptr *)>pmode_gdt);
 
+   /*
+* We have to check that we can write back the value, and not
+* just read it.  At least on 90 nm Pentium M (Family 6, Model
+* 13), reading an invalid MSR is not guaranteed to trap, see
+* Erratum X4 in "Intel Pentium M Processor on 90 nm Process
+* with 2-MB L2 Cache and Intel® Processor A100 and A110 on 90
+* nm process with 512-KB L2 Cache Specification Update".
+*/
if (!rdmsr_safe(MSR_EFER,
>pmode_efer_low,
-   >pmode_efer_high))
+   >pmode_efer_high) &&
+   !wrmsr_safe(MSR_EFER,
+   header->pmode_efer_low,
+   header->pmode_efer_high))
header->pmode_behavior |= (1 << WAKEUP_BEHAVIOR_RESTORE_EFER);
 #endif /* !CONFIG_64BIT */
 
@@ -61,7 +72,10 @@ int x86_acpi_suspend_lowlevel(void)
}
if (!rdmsr_safe(MSR_IA32_MISC_ENABLE,
>pmode_misc_en_low,
-   >pmode_misc_en_high))
+   >pmode_misc_en_high) &&
+   !wrmsr_safe(MSR_IA32_MISC_ENABLE,
+   header->pmode_misc_en_low,
+   header->pmode_misc_en_high))
header->pmode_behavior |=
(1 << WAKEUP_BEHAVIOR_RESTORE_MISC_ENABLE);
header->realmode_flags = acpi_realmode_flags;
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 5e4d8a8..e1aabdb 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -512,21 +512,6 @@ ENTRY(phys_base)
 
 #include "../../x86/xen/xen-head.S"

-   .section .bss, "aw", @nobits
-   .align L1_CACHE_BYTES
-ENTRY(idt_table)
-   .skip IDT_ENTRIES * 16
-
-   .align L1_CACHE_BYTES
-ENTRY(debug_idt_table)
-   .skip IDT_ENTRIES * 16
-
-#ifdef CONFIG_TRACING
-   .align L1_CACHE_BYTES
-ENTRY(trace_idt_table)
-   .skip IDT_ENTRIES * 16
-#endif
-
__PAGE_ALIGNED_BSS
 NEXT_PAGE(empty_zero_page)
.skip PAGE_SIZE
diff --git a/arch/x86/kernel/tracepoint.c b/arch/x86/kernel/tracepoint.c
index 4e584a8..1c113db 100644
--- a/arch/x86/kernel/tracepoint.c
+++ b/arch/x86/kernel/tracepoint.c
@@ -12,10 +12,8 @@ atomic_t trace_idt_ctr = ATOMIC_INIT(0);
 struct desc_ptr trace_idt_descr = { NR_VECTORS * 16 - 1,
(unsigned long) trace_idt_table };
 
-#ifndef CONFIG_X86_64
-gate_desc trace_idt_table[NR_VECTORS] __page_aligned_data
-   = { { { { 0, 0 } } }, };
-#endif
+/* No need to be aligned, but done to keep all IDTs defined the same way. */
+gate_desc trace_idt_table[NR_VECTORS] __page_aligned_bss;
 
 static int trace_irq_vector_refcount;
 static DEFINE_MUTEX(irq_vector_mutex);
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index b0865e8..1b23a1c 100644
--- 

[GIT PULL] x86 fixes for 3.11-rc2

2013-07-18 Thread H. Peter Anvin
Hi Linus,

Trying again to get the fixes queue, including the fixed IDT alignment
patch.

The UEFI patch is by far the biggest issue at hand: it is currently
causing quite a few machines to boot.  Which is sad, because the only
reason they would is because their BIOSes touch memory that has
already been freed.  The other major issue is that we finally have
tracked down the root cause of a significant number of machines
failing to suspend/resume.

Toivottavasti sinun ei tarvitse kutsua minua perkeleen vittupää tällä
kertaa.

The following changes since commit 6d128e1e72bf082542e85f72e6b7ddd704193588:

  Revert Makefile: Fix install error with make -j option (2013-07-10 19:02:51 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus

for you to fetch changes up to 4df05f361937ee86e5a8c9ead8aeb6a19ea9b7d7:

  x86: Make sure IDT is page aligned (2013-07-16 15:14:48 -0700)


H. Peter Anvin (1):
  x86, suspend: Handle CPUs which fail to #GP on RDMSR

Kees Cook (1):
  x86: Make sure IDT is page aligned

Matt Fleming (2):
  efivars: check for EFI_RUNTIME_SERVICES
  Revert UEFI: Don't pass boot services regions to SetVirtualAddressMap()

Xiong Zhou (1):
  x86/platform/ce4100: Add header file for reboot type

 arch/x86/kernel/acpi/sleep.c  | 18 --
 arch/x86/kernel/head_64.S | 15 ---
 arch/x86/kernel/tracepoint.c  |  6 ++
 arch/x86/kernel/traps.c   | 12 ++--
 arch/x86/platform/ce4100/ce4100.c |  1 +
 arch/x86/platform/efi/efi.c   |  7 ---
 drivers/firmware/efi/efivars.c|  3 +++
 7 files changed, 28 insertions(+), 34 deletions(-)

diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
index 2a34aaf..3312010 100644
--- a/arch/x86/kernel/acpi/sleep.c
+++ b/arch/x86/kernel/acpi/sleep.c
@@ -48,9 +48,20 @@ int x86_acpi_suspend_lowlevel(void)
 #ifndef CONFIG_64BIT
native_store_gdt((struct desc_ptr *)header-pmode_gdt);
 
+   /*
+* We have to check that we can write back the value, and not
+* just read it.  At least on 90 nm Pentium M (Family 6, Model
+* 13), reading an invalid MSR is not guaranteed to trap, see
+* Erratum X4 in Intel Pentium M Processor on 90 nm Process
+* with 2-MB L2 Cache and Intel® Processor A100 and A110 on 90
+* nm process with 512-KB L2 Cache Specification Update.
+*/
if (!rdmsr_safe(MSR_EFER,
header-pmode_efer_low,
-   header-pmode_efer_high))
+   header-pmode_efer_high) 
+   !wrmsr_safe(MSR_EFER,
+   header-pmode_efer_low,
+   header-pmode_efer_high))
header-pmode_behavior |= (1  WAKEUP_BEHAVIOR_RESTORE_EFER);
 #endif /* !CONFIG_64BIT */
 
@@ -61,7 +72,10 @@ int x86_acpi_suspend_lowlevel(void)
}
if (!rdmsr_safe(MSR_IA32_MISC_ENABLE,
header-pmode_misc_en_low,
-   header-pmode_misc_en_high))
+   header-pmode_misc_en_high) 
+   !wrmsr_safe(MSR_IA32_MISC_ENABLE,
+   header-pmode_misc_en_low,
+   header-pmode_misc_en_high))
header-pmode_behavior |=
(1  WAKEUP_BEHAVIOR_RESTORE_MISC_ENABLE);
header-realmode_flags = acpi_realmode_flags;
diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
index 5e4d8a8..e1aabdb 100644
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -512,21 +512,6 @@ ENTRY(phys_base)
 
 #include ../../x86/xen/xen-head.S

-   .section .bss, aw, @nobits
-   .align L1_CACHE_BYTES
-ENTRY(idt_table)
-   .skip IDT_ENTRIES * 16
-
-   .align L1_CACHE_BYTES
-ENTRY(debug_idt_table)
-   .skip IDT_ENTRIES * 16
-
-#ifdef CONFIG_TRACING
-   .align L1_CACHE_BYTES
-ENTRY(trace_idt_table)
-   .skip IDT_ENTRIES * 16
-#endif
-
__PAGE_ALIGNED_BSS
 NEXT_PAGE(empty_zero_page)
.skip PAGE_SIZE
diff --git a/arch/x86/kernel/tracepoint.c b/arch/x86/kernel/tracepoint.c
index 4e584a8..1c113db 100644
--- a/arch/x86/kernel/tracepoint.c
+++ b/arch/x86/kernel/tracepoint.c
@@ -12,10 +12,8 @@ atomic_t trace_idt_ctr = ATOMIC_INIT(0);
 struct desc_ptr trace_idt_descr = { NR_VECTORS * 16 - 1,
(unsigned long) trace_idt_table };
 
-#ifndef CONFIG_X86_64
-gate_desc trace_idt_table[NR_VECTORS] __page_aligned_data
-   = { { { { 0, 0 } } }, };
-#endif
+/* No need to be aligned, but done to keep all IDTs defined the same way. */
+gate_desc trace_idt_table[NR_VECTORS] __page_aligned_bss;
 
 static int trace_irq_vector_refcount;
 static DEFINE_MUTEX(irq_vector_mutex);
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index b0865e8..1b23a1c 100644
--- 

Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-18 Thread Linus Torvalds
Google translate is getting better. I was going to ask you who you
knew who had enough of a Finnish background to do that, but decided to
see what I could make google translate do.

I'm pretty sure google didn't _use_ to do that good a job at Finnish.
It would be pääksi, not pää, but I think you edited that part by
hand without knowing the rules for Finnish translative declension.

Finnish is hard. But good for swearing.

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


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-18 Thread Myklebust, Trond
On Thu, 2013-07-18 at 17:46 -0700, Linus Torvalds wrote:

 Finnish is hard. But good for swearing.

Only because the ratio of vowels to consonants causes an immediate
outbreak of swearing among those who try...

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
trond.mykleb...@netapp.com
www.netapp.com


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-18 Thread H. Peter Anvin
On 07/18/2013 05:46 PM, Linus Torvalds wrote:
 
 Finnish is hard. But good for swearing.
 

http://www.youtube.com/watch?v=b1fkMuMDqXI

It probably won't make too much sense if you haven't seen:

http://www.youtube.com/watch?v=_4bka9Y2gJ0

-hpa

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


Re: [GIT PULL] x86 fixes for 3.11-rc2

2013-07-18 Thread H. Peter Anvin
On 07/18/2013 05:46 PM, Linus Torvalds wrote:
 
 Finnish is hard. But good for swearing.
 

Ehkä meidän sääntö, että kiroilu on sallittu vain suomeksi (ja venäjä,
muuten Al Viro todennäköisesti räjähtää.)

-hpa

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