Hi,
i recently got a VIA VB8001 with their new "Nano" CPU. I just tried to
build the 2.6.28.7 Kernel in 64bit mode with padlock support... but
there seems to be none yet (i386 has the option).
Is it planned to support this in the near future?
- Tobias
there should be no difference, except
* the 64bit variant now also initializes the padlock unit.
* ->c_early_init() is executed again from ->c_init()
* the 64bit fixups made into 32bit path.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
arch/x86/Kconfig.cpu | 17 +----------------
arch/x86/kernel/cpu/Makefile | 3 +--
arch/x86/kernel/cpu/centaur.c | 30 +++++++++++++++++++++++++-----
arch/x86/kernel/cpu/centaur_64.c | 37 -------------------------------------
4 files changed, 27 insertions(+), 60 deletions(-)
delete mode 100644 arch/x86/kernel/cpu/centaur_64.c
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index a95eaf0..924e156 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -456,24 +456,9 @@ config CPU_SUP_AMD
If unsure, say N.
-config CPU_SUP_CENTAUR_32
+config CPU_SUP_CENTAUR
default y
bool "Support Centaur processors" if PROCESSOR_SELECT
- depends on !64BIT
- ---help---
- This enables detection, tunings and quirks for Centaur processors
-
- You need this enabled if you want your kernel to run on a
- Centaur CPU. Disabling this option on other types of CPUs
- makes the kernel a tiny bit smaller. Disabling it on a Centaur
- CPU might render the kernel unbootable.
-
- If unsure, say N.
-
-config CPU_SUP_CENTAUR_64
- default y
- bool "Support Centaur processors" if PROCESSOR_SELECT
- depends on 64BIT
---help---
This enables detection, tunings and quirks for Centaur processors
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 24733b4..3efcb2b 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -19,8 +19,7 @@ obj-$(CONFIG_X86_CPU_DEBUG) += cpu_debug.o
obj-$(CONFIG_CPU_SUP_INTEL) += intel.o
obj-$(CONFIG_CPU_SUP_AMD) += amd.o
obj-$(CONFIG_CPU_SUP_CYRIX_32) += cyrix.o
-obj-$(CONFIG_CPU_SUP_CENTAUR_32) += centaur.o
-obj-$(CONFIG_CPU_SUP_CENTAUR_64) += centaur_64.o
+obj-$(CONFIG_CPU_SUP_CENTAUR) += centaur.o
obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 983e083..946814a 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -276,7 +276,7 @@ static void __cpuinit init_c3(struct cpuinfo_x86 *c)
*/
c->x86_capability[5] = cpuid_edx(0xC0000001);
}
-
+#ifdef CONFIG_X86_32
/* Cyrix III family needs CX8 & PGE explicitly enabled. */
if (c->x86_model >= 6 && c->x86_model <= 9) {
rdmsr(MSR_VIA_FCR, lo, hi);
@@ -288,6 +288,11 @@ static void __cpuinit init_c3(struct cpuinfo_x86 *c)
/* Before Nehemiah, the C3's had 3dNOW! */
if (c->x86_model >= 6 && c->x86_model < 9)
set_cpu_cap(c, X86_FEATURE_3DNOW);
+#endif
+ if (c->x86 == 0x6 && c->x86_model >= 0xf) {
+ c->x86_cache_alignment = c->x86_clflush_size * 2;
+ set_cpu_cap(c, X86_FEATURE_REP_GOOD);
+ }
display_cacheinfo(c);
}
@@ -316,16 +321,25 @@ enum {
static void __cpuinit early_init_centaur(struct cpuinfo_x86 *c)
{
switch (c->x86) {
+#ifdef CONFIG_X86_32
case 5:
/* Emulate MTRRs using Centaur's MCR. */
set_cpu_cap(c, X86_FEATURE_CENTAUR_MCR);
break;
+#endif
+ case 6:
+ if (c->x86_model >= 0xf)
+ set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
+ break;
}
+#ifdef CONFIG_X86_64
+ set_cpu_cap(c, X86_FEATURE_SYSENTER32);
+#endif
}
static void __cpuinit init_centaur(struct cpuinfo_x86 *c)
{
-
+#ifdef CONFIG_X86_32
char *name;
u32 fcr_set = 0;
u32 fcr_clr = 0;
@@ -337,8 +351,10 @@ static void __cpuinit init_centaur(struct cpuinfo_x86 *c)
* 3DNow is IDd by bit 31 in extended CPUID (1*32+31) anyway
*/
clear_cpu_cap(c, 0*32+31);
-
+#endif
+ early_init_centaur(c);
switch (c->x86) {
+#ifdef CONFIG_X86_32
case 5:
switch (c->x86_model) {
case 4:
@@ -442,16 +458,20 @@ static void __cpuinit init_centaur(struct cpuinfo_x86 *c)
}
sprintf(c->x86_model_id, "WinChip %s", name);
break;
-
+#endif
case 6:
init_c3(c);
break;
}
+#ifdef CONFIG_X86_64
+ set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
+#endif
}
static unsigned int __cpuinit
centaur_size_cache(struct cpuinfo_x86 *c, unsigned int size)
{
+#ifdef CONFIG_X86_32
/* VIA C3 CPUs (670-68F) need further shifting. */
if ((c->x86 == 6) && ((c->x86_model == 7) || (c->x86_model == 8)))
size >>= 8;
@@ -464,7 +484,7 @@ centaur_size_cache(struct cpuinfo_x86 *c, unsigned int size)
if ((c->x86 == 6) && (c->x86_model == 9) &&
(c->x86_mask == 1) && (size == 65))
size -= 1;
-
+#endif
return size;
}
diff --git a/arch/x86/kernel/cpu/centaur_64.c b/arch/x86/kernel/cpu/centaur_64.c
deleted file mode 100644
index 51b09c4..0000000
--- a/arch/x86/kernel/cpu/centaur_64.c
+++ /dev/null
@@ -1,37 +0,0 @@
-#include <linux/init.h>
-#include <linux/smp.h>
-
-#include <asm/cpufeature.h>
-#include <asm/processor.h>
-
-#include "cpu.h"
-
-static void __cpuinit early_init_centaur(struct cpuinfo_x86 *c)
-{
- if (c->x86 == 0x6 && c->x86_model >= 0xf)
- set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
-
- set_cpu_cap(c, X86_FEATURE_SYSENTER32);
-}
-
-static void __cpuinit init_centaur(struct cpuinfo_x86 *c)
-{
- early_init_centaur(c);
-
- if (c->x86 == 0x6 && c->x86_model >= 0xf) {
- c->x86_cache_alignment = c->x86_clflush_size * 2;
- set_cpu_cap(c, X86_FEATURE_REP_GOOD);
- }
- set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
-}
-
-static const struct cpu_dev centaur_cpu_dev __cpuinitconst = {
- .c_vendor = "Centaur",
- .c_ident = { "CentaurHauls" },
- .c_early_init = early_init_centaur,
- .c_init = init_centaur,
- .c_x86_vendor = X86_VENDOR_CENTAUR,
-};
-
-cpu_dev_register(centaur_cpu_dev);
To enable the padlock unit, two msr bits have to flipped. This is allready
done in the 32bit path and is missing in the other. Instead of copy paste
the code, I merged the 64bit part into the 32bit part. The things that
changed during the merge:
- the fixups from x86_64 (family 6, model >= 15) were not present in 32bit
path but are now. They might be usefull if this CPU is booted in 32bit
mode.
- the fixups which are executed via ->c_early_init() are now executed
again via ->c_init(). This was done in the 64bit path and without this I
lost the constant_tsc flag. However, tsc is not useable due to
| [ 2.023006] Marking TSC unstable due to TSC halts in idle
| [ 2.500082] Clocksource tsc unstable (delta = -326436711 ns)
The two patches are against the current tip tree. A version of patch 1
against current -rc8 is available at [0].
[0] http://download.breakpoint.cc/0001-x86-centaur-merge-32-64-bit-version.patch
Sebastian
almost everything stays the same, we need just to use the extended registers
on the bit variant.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
drivers/crypto/Kconfig | 2 +-
drivers/crypto/padlock-aes.c | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index e522144..62ed61b 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -12,7 +12,7 @@ if CRYPTO_HW
config CRYPTO_DEV_PADLOCK
tristate "Support for VIA PadLock ACE"
- depends on X86_32 && !UML
+ depends on !UML
select CRYPTO_ALGAPI
help
Some VIA processors come with an integrated crypto engine
diff --git a/drivers/crypto/padlock-aes.c b/drivers/crypto/padlock-aes.c
index 3f0fdd1..ddd27c7 100644
--- a/drivers/crypto/padlock-aes.c
+++ b/drivers/crypto/padlock-aes.c
@@ -154,7 +154,11 @@ static inline void padlock_reset_key(struct cword *cword)
int cpu = raw_smp_processor_id();
if (cword != per_cpu(last_cword, cpu))
+#ifndef CONFIG_X86_64
asm volatile ("pushfl; popfl");
+#else
+ asm volatile ("pushfq; popfq");
+#endif
}
static inline void padlock_store_cword(struct cword *cword)
@@ -208,10 +212,19 @@ static inline void padlock_xcrypt_ecb(const u8 *input, u8 *output, void *key,
asm volatile ("test $1, %%cl;"
"je 1f;"
+#ifndef CONFIG_X86_64
"lea -1(%%ecx), %%eax;"
"mov $1, %%ecx;"
+#else
+ "lea -1(%%rcx), %%rax;"
+ "mov $1, %%rcx;"
+#endif
".byte 0xf3,0x0f,0xa7,0xc8;" /* rep xcryptecb */
+#ifndef CONFIG_X86_64
"mov %%eax, %%ecx;"
+#else
+ "mov %%rax, %%rcx;"
+#endif
"1:"
".byte 0xf3,0x0f,0xa7,0xc8" /* rep xcryptecb */
: "+S"(input), "+D"(output)
--
1.6.2
* Sebastian Andrzej Siewior <[email protected]> wrote:
> To enable the padlock unit, two msr bits have to flipped. This is allready
> done in the 32bit path and is missing in the other. Instead of copy paste
> the code, I merged the 64bit part into the 32bit part. The things that
> changed during the merge:
> - the fixups from x86_64 (family 6, model >= 15) were not present in 32bit
> path but are now. They might be usefull if this CPU is booted in 32bit
> mode.
> - the fixups which are executed via ->c_early_init() are now executed
> again via ->c_init(). This was done in the 64bit path and without this I
> lost the constant_tsc flag. However, tsc is not useable due to
> | [ 2.023006] Marking TSC unstable due to TSC halts in idle
> | [ 2.500082] Clocksource tsc unstable (delta = -326436711 ns)
>
> The two patches are against the current tip tree. A version of
> patch 1 against current -rc8 is available at [0].
thanks, looks good. We can apply #1 to -tip just fine - but a
drivers/crypto/ change should go via the crypto tree. Can the
crypto tree apply #2 without having #1 right away? [i.e. will it
still build and boot fine - even though the padlock
functionality might not be fully present on 32-bit? ]
Then in 2.6.30 once both the x86 tree and the crypto tree are
merged we'll have both changes combined.
Does that sound good?
Ingo
* Ingo Molnar | 2009-03-14 12:47:32 [+0100]:
>thanks, looks good. We can apply #1 to -tip just fine - but a
>drivers/crypto/ change should go via the crypto tree. Can the
>crypto tree apply #2 without having #1 right away? [i.e. will it
>still build and boot fine - even though the padlock
>functionality might not be fully present on 32-bit? ]
Yep, it is fine.
#1 in, #2 not will not result in any difference to what we have now.
#2 in, #1 not will result in "padlock not detected" while loading the
module and -ENODEV.
>Then in 2.6.30 once both the x86 tree and the crypto tree are
>merged we'll have both changes combined.
>
>Does that sound good?
I'm fine with this, but last word is Herbert's :)
> Ingo
Sebastian
On Sat, Mar 14, 2009 at 12:53:07PM +0100, Sebastian Andrzej Siewior wrote:
>
> Yep, it is fine.
> #1 in, #2 not will not result in any difference to what we have now.
> #2 in, #1 not will result in "padlock not detected" while loading the
> module and -ENODEV.
Let's merge #1 right now and I'll pick up #2 once #1 shows up
in linux-net.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sat, 14 Mar 2009 21:24:20 +0800
Herbert Xu <[email protected]> wrote:
> On Sat, Mar 14, 2009 at 12:53:07PM +0100, Sebastian Andrzej Siewior wrote:
> >
> > Yep, it is fine.
> > #1 in, #2 not will not result in any difference to what we have now.
> > #2 in, #1 not will result in "padlock not detected" while loading the
> > module and -ENODEV.
>
> Let's merge #1 right now and I'll pick up #2 once #1 shows up
> in linux-net.
>
#1 is in 2.6.30-rc now but I don't see #2 pending anywhere.
On Mon, Apr 20, 2009 at 06:09:31PM -0400, Chuck Ebbert wrote:
>
> #1 is in 2.6.30-rc now but I don't see #2 pending anywhere.
Thanks for the reminder. I've now added it to cryptodev.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt