i686 quirk for AMD Geode
in [Kernel]
|
Prev: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
Next: drm/ksm -> s2disk -> resume -> [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
From: H. Peter Anvin on 7 Nov 2009 21:20 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 8 Nov 2009 11:20 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 8 Nov 2009 12:40 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 8 Nov 2009 12:50 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 8 Nov 2009 13:10
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/ |