[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1242734255.3377.20.camel@localhost.localdomain>
Date: Tue, 19 May 2009 17:27:35 +0530
From: Jaswinder Singh Rajput <jaswinder@...nel.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: "H. Peter Anvin" <hpa@...or.com>, x86 maintainers <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [git-pull -tip] x86: cpu_debug patches
Hello Ingo,
On Sun, 2009-05-03 at 11:09 +0200, Ingo Molnar wrote:
> * Jaswinder Singh Rajput <jaswinder@...nel.org> wrote:
>
> > We can use cpu_has tests for unknown processors but 'cpu model' is
> > accurate and cover all range.
> >
> > cpu_has does not cover following registers:
> > 1. platform
> > 2. poweron
> > 3. control
> > 4. bios
> > 5. freq
> > 6. cache
> > 7. misc
> > 8. base
> > 9. ver
> > 10. conf
>
> Firstly these should be added to cpufeatures.h.
>
> Then add cpu_has_xxx() accessors need to be added for them and
> during CPU init they have to be properly set, via two methods:
>
> - via CPUID (where this is possible+specified in docs)
> - or via "later than CPU version X" checks
>
> Your cpu-model table is equivalent to an explicitly enumerated CPU
> version check, but this breaks every time a new CPU comes out.
>
> "Later than" or CPUID based feature bits are a lot more future-proof
> - we only have to add support for new _features_ (and quirks,
> occasionally), and dont have to maintain that full table of specific
> models to specific features mapping tables.
>
It seems that other developers have some objections for adding new cpuid
features.
May be we can try accessing MSRs without any checking, it will work on
new processors but we need to check it on old processors, so I will need
your help to run this modules on old processors.
Now what should be the next step.
Thanks,
--
JSR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists