[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090305140809.GA27962@elte.hu>
Date: Thu, 5 Mar 2009 15:08:09 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Andreas Herrmann <andreas.herrmann3@....com>
Cc: Jaswinder Singh Rajput <jaswinder@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, x86 maintainers <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git-pull -tip] x86: msr architecture debug code
* Andreas Herrmann <andreas.herrmann3@....com> wrote:
> On Mon, Mar 02, 2009 at 09:54:37PM +0100, Ingo Molnar wrote:
> > * Jaswinder Singh Rajput <jaswinder@...nel.org> wrote:
>
> Oops, didn't read this mail till the end.
> Thus I missed this part.
>
> > > +{
> > > + struct cpuinfo_x86 *cpu = &cpu_data(0);
> > > +
> > > + if (!cpu_has(cpu, X86_FEATURE_MSR))
> > > + return -ENODEV;
> > > +
> > > + msr_dir = debugfs_create_dir("msr", arch_debugfs_dir);
> > > +
> > > + msr_file = debugfs_create_file("msr", S_IRUGO, msr_dir,
> > > + NULL, &msr_fops);
> > > + pmc_file = debugfs_create_file("pmc", S_IRUGO, msr_dir,
> > > + NULL, &pmc_fops);
> >
> > I think it would be possible to have a much more intuitive file
> > layout under /debug/x86/msr/ than these two /debug/x86/msr/msr
> > and /debug/x86/msr/pmc files.
> >
> > Firstly, it should move one level deeper, to /debug/x86/cpu/msr/
> > - because the MSR is really a property of the CPU, and there are
> > other properties of the CPU we might want to expose in the
> > future.
> >
> > Secondly, the picking of debugfs (as opposed to sysfs) is a good
> > choice, because we probably want to tweak the layout a number of
> > times and want to keep flexibility, without being limited by the
> > sysfs ABI.
> >
> > So i like the idea - but we really want to do even more and add
> > more structure to this. If we just want dumb msr enumeration we
> > already have /dev/msr.
> >
> > Regarding the msr directory: one good approach would be to have
> > have several "topic" directories under /debug/x86/cpu/msr/.
> >
> > One such topic would be the 'pmu', with a structure like:
> >
> > /debug/x86/cpu/msr/pmu/
> > /debug/x86/cpu/msr/pmu/pmc_0/
> > /debug/x86/cpu/msr/pmu/pmc_0/counter
> > /debug/x86/cpu/msr/pmu/pmc_0/eventsel
> >
> > There would also be a /debug/x86/cpu/msr/raw/ directory with all
> > MSR numbers we know about explicitly, for example:
> >
> > /debug/x86/cpu/msr/raw/0x372/value
> > /debug/x86/cpu/msr/raw/0x372/width
>
> Having this stuff in the kernel unnecessarily bloats up kernel code.
it should be a default-off Kconfig option and it is in debugfs
so there's no real bloat issue here.
> What the kernel needs to provide is a reliable interface to
> access MSRs -- to pass the data to userspace. This interface
> is already there.
>
> IMHO all kind of parsing and grouping of that data belongs in
> user space.
>
> One exception are MSRs that need to be checked early during
> boot (e.g. MTRRs). For debugging purposes you might want to
> dump certain MSRs early. But then you will use printk and not
> debugfs.
Well it's really nice to know the _kernel's_ enumeration of MSRs
and its knowledge about the structure of those MSRs.
Sure, we can and do export the flat MSR space to user-space, but
the kernel also enumerates them internally, in various places.
The debugfs interface shows them in one way - and as such also
acts as a central force to keep these things tidy.
a VFS namespace is also pretty educative. You can see which MSRs
matter to the lapic for example, you can see their symbolic
names, their current state, etc. etc.
> > Maybe a symlink pointing it back to the topic directory
> > would be useful as well. For example:
> >
> > /debug/x86/cpu/msr/raw/0x372/topic_dir -> /debug/x86/cpu/msr/pmu/pmc_0/
> >
> > Other "topic directories" are possible too: a
> > /debug/x86/cpu/msr/apic/ layout would be very useful and
> > informative as well, and so are some of the other MSRs we
> > tweak during bootup.
>
> All nice suggestions but why in-kernel?
>
> Just hack some script to do this. This is much more
> maintainable. You don't need a kernel update to add support
> for new CPUs or to fix bugs in this code itself -- you just
> have to tweak your script.
the kernel tends to know a lot about these MSRs already so we
just provide that information in a more structured form as well.
Such more structured form, beyond the debugging and
education/development advantages, also acts as a counter-force
back to the MSR enumeration code of the kernel and makes them
more structured. It will no doubt also extend the kernel's
knowledge of MSRs - read-only MSRs we dont normally read.
There's also a few other things like the IRR readout in the APIC
code or the perfcounters status dump can also be done cleanly
via /debug/x86/cpu/msr/.
Eventually i'd like /debug/x86/ to become a full CPU state dump:
the kernel pagetable dumping code could go there, we could show
control registers, we could show the GDT and IDT settings and
contents, etc. etc.
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