Re: [GIT PULL] x86 fixes for 3.11-rc2
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/