public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jaswinder Singh Rajput <jaswinder@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [GIT-PULL -tip] x86: xpu_debug patches
Date: Wed, 10 Jun 2009 21:27:31 +0530	[thread overview]
Message-ID: <1244649451.3295.5.camel@ht.satnam> (raw)
In-Reply-To: <20090608083947.GC6372@elte.hu>

Hello Ingo,

On Mon, 2009-06-08 at 10:39 +0200, Ingo Molnar wrote:
> * Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
> 
> > Ingo,
> > 
> > Please pull cpu_debug patches :
> > 
> > The following changes since commit 5095f59bda6793a7b8f0856096d6893fe98e0e51:
> >   Jaswinder Singh Rajput (1):
> >         x86: cpu_debug: Remove model information to reduce encoding-decoding
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/jaswinder/linux-2.6-cpu.git x86/cpu
> > 
> > Jaswinder Singh Rajput (5):
> >       x86: cpu_debug update Kconfig entry
> >       x86: cpu_debug.c remove some not required header files
> >       x86: cpu_debug.c use a WARN_ONCE() instead of a pr_err()
> >       x86: cpu_debug make room to support more categories
> >       x86: cpu_debug update MSR list to support new architectures
> > 
> >  arch/x86/Kconfig                 |   12 ++++-
> >  arch/x86/include/asm/cpu_debug.h |  102 +++++++++++++-------------------------
> >  arch/x86/kernel/cpu/cpu_debug.c  |   45 +++++++++-------
> >  3 files changed, 70 insertions(+), 89 deletions(-)
> > 
> > Complete diff:
> > 
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index a6efe0a..cd2debd 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -955,9 +955,19 @@ config X86_CPUID
> >  
> >  config X86_CPU_DEBUG
> >  	tristate "/sys/kernel/debug/x86/cpu/* - CPU Debug support"
> > +	select DEBUG_FS
> >  	---help---
> >  	  If you select this option, this will provide various x86 CPUs
> > -	  information through debugfs.
> > +	  information through debugfs. Any user can read these file but writing
> > +	  needs root privilege.
> > +
> > +	  Note: 1. If you compile cpu_debug as a module, it will _not_ be loaded
> > +	  automatically (like usual drivers). You will need to load it manually
> > +	  (or add it to list of modules loaded during boot).
> > +
> > +	  2. You need debugfs, if you want to mount debugfs automatically
> > +	  append this line in /etc/fstab:
> > +	  debugfs	/sys/kernel/debug	debugfs	defaults	0 0
> 
> Those look like good fixes - but before we start extending on all 
> this - a more general question has to be raised: do people find this 
> useful?
> 
> I had a look at the current /debug/x86/cpu*/ layout, and a fair 
> portion of it looks completely meaningless at the moment: there's a 
> lot of hexa fields with absolutely zero symbolic information about 
> what the fields actually mean.
> 
> There's a few good exceptions like /debug/x86/cpu/cpu0/apic/apic or 
> /debug/x86/cpu/cpu0/cr/cr, although even those should probably be 
> renamed to:
> 
>   /debug/x86/cpu/cpu0/apic/state
>   /debug/x86/cpu/cpu0/cr/state
> 
> as 'apic/apic' and 'cr/cr' is meaningless.
> 
> Or better yet, why isnt there a directory structure to known values:
> 
>   /debug/x86/cpu/cpu0/apic/LVTERR/value
> 
> ?
> 
> This would allow the changing/reading of all known values.
> 
> The 'total state' could still be accessed easily as well, via:
> 
>   cat /debug/x86/cpu/cpu0/apic/*/value
> 
> Paradoxically, all the _unknown_ values have a split out per 
> register layout. I.e. the namespace is bloated with a lot of 
> 'unknown' state - while the 'known' (and printed/interpreted) 
> registers are hidden and collected into meaninglessly named files. 
> It should be exactly the other way around.
> 

I tried to fix few of the issues you pointed and send new pull request,
Can you please pull it :

[git-pull -tip] cpu_debug patches 20090610

> All in one, this code either needs to become useful in practice, 
> needs to provide a nice, structured, intuitive 'view' of the CPU's 
> current state (as known to the kernel) - or it should not be done at 
> all.
> 
> If we want a quirky interface we can use msr-tools and /sbin/rdmsr 
> just fine. So /debug/x86/cpu/ really has to become a strikingly 
> intuitive big step forward in terms of CPU state enumeration and 
> visualization, for it to make sense to be carried in the kernel.
> 

I am adding more features in cpu_debug to make it more useful.

Thanks,
--
JSR


      parent reply	other threads:[~2009-06-10 15:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-08  7:58 [GIT-PULL -tip] x86: xpu_debug patches Jaswinder Singh Rajput
2009-06-08  8:39 ` Ingo Molnar
2009-06-08  9:10   ` Jaswinder Singh Rajput
2009-06-10 15:57   ` Jaswinder Singh Rajput [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1244649451.3295.5.camel@ht.satnam \
    --to=jaswinder@kernel.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox