lkml.org 
[lkml]   [2009]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [git-pull -tip] x86: msr architecture debug code

    * Andreas Herrmann <andreas.herrmann3@amd.com> wrote:

    > On Mon, Mar 02, 2009 at 09:54:37PM +0100, Ingo Molnar wrote:
    > > * Jaswinder Singh Rajput <jaswinder@kernel.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


    \
     
     \ /
      Last update: 2009-03-05 15:11    [W:0.030 / U:180.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site