[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090305141129.GB27962@elte.hu>
Date: Thu, 5 Mar 2009 15:11:29 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Jaswinder Singh Rajput <jaswinder@...nel.org>
Cc: Andreas Herrmann <andreas.herrmann3@....com>,
"H. Peter Anvin" <hpa@...or.com>, x86 maintainers <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git-pull -tip V2] x86: msr architecture debug code
* Jaswinder Singh Rajput <jaswinder@...nel.org> wrote:
> On Thu, 2009-03-05 at 14:32 +0100, Ingo Molnar wrote:
> > * Andreas Herrmann <andreas.herrmann3@....com> wrote:
> >
> > > - I've just one directory in debugfs
> > > x86/cpu/msr/cpu0
> > > The system has a quad-core CPU. So I guess there should be 4
> > > directories -- one for each core.
> >
> > Correct, most MSRs are per core - that needs to be fixed.
>
> Ok I will support all cores in next Version.
the VFS structure should be something like:
/debug/x86/cpu/cpu0/msr/...
I.e. first we have the CPU, then a specific CPU, and MSRs are
attributes of that CPU (core).
Maybe the topical setup shouldnt even include 'msr' in its name
- that way we'll be able to add non-MSR information too. I.e.
we'd have:
/debug/x86/cpu/cpu0/apic/...
/debug/x86/cpu/cpu0/pmu/...
/debug/x86/cpu/cpu0/cpu_features/...
Populated with symbolic MSR entries for the time being.
Another detail: there are MSRs that are shared between
cores/CPUs/sockets on certain models - but that's not a big
issue, the readouts will be mirrored.
Ingo
--
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