From: H. Peter Anvin on
On 11/07/2009 03:11 AM, Matteo Croce wrote:
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ b/arch/x86/kernel/nopl_emu.c 2009-11-07 11:59:17.667748571 +0100
> @@ -0,0 +1,103 @@
> +/*
> + * linux/arch/x86/kernel/nopl_emu.c
> + *
> + * Copyright (C) 2002 Willy Tarreau
> + * Copyright (C) 2009 Matteo Croce
> + */
> +
> +#include <linux/linkage.h>
> +#include <asm/math_emu.h>
> +#include <asm/traps.h>
> +
> +/* This code can be used to allow the AMD Geode to hopefully correctly execute
> + * some code which was originally compiled for an i686, by emulating NOPL,
> + * the only missing i686 instruction in the CPU
> + *
> + * Willy Tarreau <willy(a)meta-x.org>
> + * Matteo Croce <technoboy85(a)gmail.com>
> + */
> +

If we're doing to introduce a missed-instruction interpreter (which is
what this is) in the kernel, it needs to handle all the subtleties of
x86 execution correctly; in particular I believe it needs to check the
code segment limits, permissions, and mode. Things it doesn't
understand it can SIGILL (or, if more appropriate, SIGSEGV) on, of course.

Personally I think the easiest is to verify that the code segment is
flat 32 bits or even more specifically CS == USER_CS, and SIGILL otherwise.

-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: Andres Salomon on
See comment below. BTW, how does this affect performance on LXs?
Do you have any hard numbers for common tasks?

On Sat, 7 Nov 2009 12:11:55 +0100
Matteo Croce <technoboy85(a)gmail.com> wrote:
[...]
>
> --- a/arch/x86/kernel/Makefile 2009-11-06 15:06:52.246223989
> +0100 +++ b/arch/x86/kernel/Makefile 2009-11-06
> 15:07:04.294054613 +0100 @@ -89,7 +89,7 @@
> obj-$(CONFIG_HPET_TIMER) += hpet.o
>
> obj-$(CONFIG_K8_NB) += k8.o
> -obj-$(CONFIG_MGEODE_LX) += geode_32.o mfgpt_32.o
> +obj-$(CONFIG_MGEODE_LX) += geode_32.o mfgpt_32.o
> nopl_emu.o obj-$(CONFIG_DEBUG_RODATA_TEST) += test_rodata.o
> obj-$(CONFIG_DEBUG_NX_TEST) += test_nx.o
>
> --- a/arch/x86/kernel/cpu/amd.c 2009-11-06 15:06:52.254223805
> +0100 +++ b/arch/x86/kernel/cpu/amd.c 2009-11-06
> 15:07:04.294054613 +0100 @@ -138,8 +138,10 @@
> }
>
> if (c->x86_model == 10) {
> - /* AMD Geode LX is model 10 */
> - /* placeholder for any needed mods */
> + /* Geode only lacks the NOPL instruction to be i686,
> + but we can emulate it in the exception handler
> + and promote it to a class 6 cpu */
> + boot_cpu_data.x86 = 6;
> return;
> }

If you're going to update this, you also need to make sure that you're
not breaking things that check it. For example,
arch/x86/include/asm/geode.h has an is_geode_lx check that expects
boot_cpu_data.x86 to be 5. Please be sure to update all these places
when creating a patch like this.


--
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: Pavel Machek on
On Fri 2009-11-06 23:18:06, Matteo Croce wrote:
> On Fri, Nov 6, 2009 at 5:44 PM, H. Peter Anvin <hpa(a)zytor.com> wrote:
> > On 11/06/2009 06:59 AM, Matteo Croce wrote:
> >> indeed it has MMX, MMXEXT and CMOV, just lacks the long NOP instruction (NOPL).
> >
> > MMX and MMXEXT are hardly hallmarks of i686, which leaves only cmov.
> > I'm somewhat wondering about the general value of this patch; is i686
> > code really that much faster on Geode that it's worth it?
> >
> > ? ? ? ?-hpa
> >
> > --
> > H. Peter Anvin, Intel Open Source Technology Center
> > I work for Intel. ?I don't speak on their behalf.
> >
> >
>
> yes, I did some test like gzip, bzip2, lame etc and they give more or less
> the same results of dhrystone
>
> root(a)alix:/usr/src# CFLAGS='-march=i586' ./dry.c
> Microseconds for one run through Dhrystone: 1.4
> Dhrystones per Second: 740741
....
> root(a)alix:/usr/src# CFLAGS='-march=i686' ./dry.c
> Trying 5000000 runs through Dhrystone:
> Microseconds for one run through Dhrystone: 1.2
> Dhrystones per Second: 841751

Teach gcc that geodelx exists? No need to break kernel for that... and
you probably can gain even bigger gains.
Pavel

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: Matteo Croce on
On Sun, Nov 8, 2009 at 6:37 PM, Pavel Machek <pavel(a)ucw.cz> wrote:
> On Fri 2009-11-06 23:18:06, Matteo Croce wrote:
>> On Fri, Nov 6, 2009 at 5:44 PM, H. Peter Anvin <hpa(a)zytor.com> wrote:
>> > On 11/06/2009 06:59 AM, Matteo Croce wrote:
>> >> indeed it has MMX, MMXEXT and CMOV, just lacks the long NOP instruction (NOPL).
>> >
>> > MMX and MMXEXT are hardly hallmarks of i686, which leaves only cmov.
>> > I'm somewhat wondering about the general value of this patch; is i686
>> > code really that much faster on Geode that it's worth it?
>> >
>> > ? ? ? ?-hpa
>> >
>> > --
>> > H. Peter Anvin, Intel Open Source Technology Center
>> > I work for Intel. ?I don't speak on their behalf.
>> >
>> >
>>
>> yes, I did some test like gzip, bzip2, lame etc and they give more or less
>> the same results of dhrystone
>>
>> root(a)alix:/usr/src# CFLAGS='-march=i586' ./dry.c
>> Microseconds for one run through Dhrystone: � � � �1.4
>> Dhrystones per Second: � � � � � � � � � � � � �740741
> ...
>> root(a)alix:/usr/src# CFLAGS='-march=i686' ./dry.c
>> Trying 5000000 runs through Dhrystone:
>> Microseconds for one run through Dhrystone: � � � �1.2
>> Dhrystones per Second: � � � � � � � � � � � � �841751
>
> Teach gcc that geodelx exists? No need to break kernel for that... and
> you probably can gain even bigger gains.
> � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �Pavel

Gcc 4.4 already knows about it, just sucks at optimizing:

# CFLAGS='-march=geode' ./dry.c
gcc -c -O3 -march=geode ./dry.c -o dry1.o
gcc -DPASS2 -O3 -march=geode ./dry.c dry1.o -o dry2

Dhrystone Benchmark, Version C, Version 2.2
Program compiled without 'register' attribute
Using times(), HZ=100

Trying 5000000 runs through Dhrystone:
Microseconds for one run through Dhrystone: 1.4
Dhrystones per Second: 719424
--
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: Matteo Croce on
On Sun, Nov 8, 2009 at 5:05 PM, Andres Salomon <dilinger(a)collabora.co.uk> wrote:
> See comment below. �BTW, how does this affect performance on LXs?
> Do you have any hard numbers for common tasks?
>
> On Sat, 7 Nov 2009 12:11:55 +0100
> Matteo Croce <technoboy85(a)gmail.com> wrote:
> [...]
>>
>> --- a/arch/x86/kernel/Makefile � � � �2009-11-06 15:06:52.246223989
>> +0100 +++ b/arch/x86/kernel/Makefile �2009-11-06
>> 15:07:04.294054613 +0100 @@ -89,7 +89,7 @@
>> �obj-$(CONFIG_HPET_TIMER) � � += hpet.o
>>
>> �obj-$(CONFIG_K8_NB) � � � � �+= k8.o
>> -obj-$(CONFIG_MGEODE_LX) � � � � � � �+= geode_32.o mfgpt_32.o
>> +obj-$(CONFIG_MGEODE_LX) � � � � � � �+= geode_32.o mfgpt_32.o
>> nopl_emu.o obj-$(CONFIG_DEBUG_RODATA_TEST) � �+= test_rodata.o
>> �obj-$(CONFIG_DEBUG_NX_TEST) �+= test_nx.o
>>
>> --- a/arch/x86/kernel/cpu/amd.c � � � 2009-11-06 15:06:52.254223805
>> +0100 +++ b/arch/x86/kernel/cpu/amd.c 2009-11-06
>> 15:07:04.294054613 +0100 @@ -138,8 +138,10 @@
>> � � � }
>>
>> � � � if (c->x86_model == 10) {
>> - � � � � � � /* AMD Geode LX is model 10 */
>> - � � � � � � /* placeholder for any needed mods */
>> + � � � � � � /* Geode only lacks the NOPL instruction to be i686,
>> + � � � � � � � �but we can emulate it in the exception handler
>> + � � � � � � � �and promote it to a class 6 cpu */
>> + � � � � � � boot_cpu_data.x86 = 6;
>> � � � � � � � return;
>> � � � }
>
> If you're going to update this, you also need to make sure that you're
> not breaking things that check it. �For example,
> arch/x86/include/asm/geode.h has an is_geode_lx check that expects
> boot_cpu_data.x86 to be 5. �Please be sure to update all these places
> when creating a patch like this.
>

True, but also remove the duplicate function is_geode in the NAND driver
and use the identical one defined in geode.h:

--- a/drivers/mtd/nand/cs553x_nand.c 2009-11-08 18:58:14.835043214 +0100
+++ b/drivers/mtd/nand/cs553x_nand.c 2009-11-08 19:00:07.914117831 +0100
@@ -30,6 +30,7 @@

#include <asm/msr.h>
#include <asm/io.h>
+#include <asm/geode.h>

#define NR_CS553X_CONTROLLERS 4

@@ -260,23 +261,6 @@
return err;
}

-static int is_geode(void)
-{
- /* These are the CPUs which will have a CS553[56] companion chip */
- if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
- boot_cpu_data.x86 == 5 &&
- boot_cpu_data.x86_model == 10)
- return 1; /* Geode LX */
-
- if ((boot_cpu_data.x86_vendor == X86_VENDOR_NSC ||
- boot_cpu_data.x86_vendor == X86_VENDOR_CYRIX) &&
- boot_cpu_data.x86 == 5 &&
- boot_cpu_data.x86_model == 5)
- return 1; /* Geode GX (n�e GX2) */
-
- return 0;
-}
-

#ifdef CONFIG_MTD_PARTITIONS
static const char *part_probes[] = { "cmdlinepart", NULL };
--
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/