x86, AMD: Extend support to future families
PATCH 1/1 x86, AMD: Extend support to future families
Extend support to future families, and in particular:
* extend direct mapping split of Tseg SMM area.
* extend K8 flavored alternatives (NOPS).
* rep movs* prefix is fast in ucode.
--- arch/x86/kernel/cpu/amd.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
arch/x86/kernel/cpu/amd.c +3 -3
@@ -466,7 +466,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) } } -if (c->x86 ==0x10 || c->x86 ==0x11 ) +if (c->x86 >=0x10 )set_cpu_cap (c,X86_FEATURE_REP_GOOD );/* get apicid instead of initial apic id from cpuid */
@@ -529,7 +529,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) num_cache_leaves =3 ; } -if (c->x86 >=0xf && c->x86 <=0x11 ) +if (c->x86 >=0xf )set_cpu_cap (c,X86_FEATURE_K8 );if (cpu_has_xmm2) {
@@ -546,7 +546,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)fam10h_check_enable_mmcfg (); } -if (c == &boot_cpu_data && c->x86 >=0xf && c->x86 <=0x11 ) { +if (c == &boot_cpu_data && c->x86 >=0xf ) {unsigned long long tseg;/*
Signature · 9 lines
1.6.4.4 -- Regards/Gruss, Boris. Operating Systems Research Center Advanced Micro Devices, Inc.
H. Peter Anvin
reviewerQuoted 7 lines · Borislav Petkov
Extend support to future families, and in particular:
* extend direct mapping split of Tseg SMM area.
* extend K8 flavored alternatives (NOPS).
* rep movs* prefix is fast in ucode.Signed-off-by Borislav Petkov <[email protected]>
This doesn't reflect any currently shipping hardware, right?
-hpa
From: "H. Peter Anvin" <[email protected]>
Date: Wed, Jun 09, 2010 at 06:53:12PM -0400
Quoted 10 lines · Borislav Petkov
Quoted 7 lines
Extend support to future families, and in particular:
* extend direct mapping split of Tseg SMM area.
* extend K8 flavored alternatives (NOPS).
* rep movs* prefix is fast in ucode.Signed-off-by Borislav Petkov <[email protected]>This doesn't reflect any currently shipping hardware, right?
Not yet. And I'm assuming you're driving at tagging it for -stable? If yes, I think a stable tag makes sense since this way the distros will pick it up more easily and we most definitely will need to do the backport later otherwise.
Do you need another version with the stable tag resent or is it easier for you to edit the commit message of the one you have already?
Thanks.
Signature · 5 lines
Regards/Gruss, Boris. Operating Systems Research Center Advanced Micro Devices, Inc.
H. Peter Anvin
reviewerQuoted 9 lines · Borislav Petkov
Not yet. And I'm assuming you're driving at tagging it for -stable? If yes, I think a stable tag makes sense since this way the distros will pick it up more easily and we most definitely will need to do the backport later otherwise.
Do you need another version with the stable tag resent or is it easier for you to edit the commit message of the one you have already?
No, I'm not -- Linus is being really snippy about wanting regressions only this cycle, which this is not. Once .35 is out you can talk to Greg about -stable.
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
From: "H. Peter Anvin" <[email protected]>
Date: Sat, Jun 12, 2010 at 02:22:09PM -0400
Quoted 7 lines · Borislav Petkov
Quoted 6 lines
Not yet. And I'm assuming you're driving at tagging it for -stable? If yes, I think a stable tag makes sense since this way the distros will pick it up more easily and we most definitely will need to do the backport later otherwise.
Quoted 6 lines
Quoted 3 lines
Do you need another version with the stable tag resent or is it easier for you to edit the commit message of the one you have already?
No, I'm not -- Linus is being really snippy about wanting regressions only this cycle, which this is not.
Yeah, so I heard :)
Quoted 1 line
Once .35 is out you can talk to Greg about -stable.
Right, so this is clearly .36 merge window material - I just thought I should get it out as early as possible so that it gets tested.
And by the way, how about a tag which says which kernel is the patch aimed at so that maintainers know what should go where. I mean, with those gazillion patches on lkml one doesn't always know which is regression, which is a new feature but should go in earlier so that it catches the next merge window etc? I.e., something like:
Aimed-at: 2.6.36+
or for regressions
Aimed-at: 2.6.35-rc3
and maybe even a bug info
I'm afraid this is starting to sound like Ingo's Impact: tag, at least semantically, which didn't get accepted. Hmm, anyway, I'll try adding such an information in later patches.
Thanks.
Signature · 5 lines
Regards/Gruss, Boris. Operating Systems Research Center Advanced Micro Devices, Inc.
Commit-ID: 12d8a961289644d265d8b3e88201878837c3b814 Gitweb: http://git.kernel.org/tip/12d8a961289644d265d8b3e88201878837c3b814 Author: Borislav Petkov <[email protected]> AuthorDate: Wed, 2 Jun 2010 20:29:21 +0200 Committer: H. Peter Anvin <[email protected]> CommitDate: Wed, 9 Jun 2010 15:57:47 -0700
x86, AMD: Extend support to future families
Extend support to future families, and in particular:
* extend direct mapping split of Tseg SMM area.
* extend K8 flavored alternatives (NOPS).
* rep movs* prefix is fast in ucode.
LKML-Reference: <20100602182921.GA21557@aftab>
--- arch/x86/kernel/cpu/amd.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
arch/x86/kernel/cpu/amd.c +3 -3
@@ -466,7 +466,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) } } -if (c->x86 ==0x10 || c->x86 ==0x11 ) +if (c->x86 >=0x10 )set_cpu_cap (c,X86_FEATURE_REP_GOOD );/* get apicid instead of initial apic id from cpuid */
@@ -529,7 +529,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) num_cache_leaves =3 ; } -if (c->x86 >=0xf && c->x86 <=0x11 ) +if (c->x86 >=0xf )set_cpu_cap (c,X86_FEATURE_K8 );if (cpu_has_xmm2) {
@@ -546,7 +546,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)fam10h_check_enable_mmcfg (); } -if (c == &boot_cpu_data && c->x86 >=0xf && c->x86 <=0x11 ) { +if (c == &boot_cpu_data && c->x86 >=0xf ) {unsigned long long tseg;/*