From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756917AbcBIMXI (ORCPT <rfc822;w@1wt.eu>);
	Tue, 9 Feb 2016 07:23:08 -0500
Received: from mail-wm0-f67.google.com ([74.125.82.67]:32882 "EHLO
	mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756853AbcBIMXE (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 9 Feb 2016 07:23:04 -0500
Date: Tue, 9 Feb 2016 13:23:00 +0100
From: Ingo Molnar <mingo@kernel.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@alien8.de>, "Luck, Tony" <tony.luck@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@amacapital.net>,
        Peter Zijlstra <peterz@infradead.org>,
        Steven Rostedt <rostedt@goodmis.org>, Brian Gerst <brgerst@gmail.com>,
        lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -v2] x86: Add an archinfo dumper module
Message-ID: <20160209122300.GA4878@gmail.com>
References: <20160201115601.GD6438@pd.tnic>
 <3908561D78D1C84285E8C5FCA982C28F39FCE0E4@ORSMSX114.amr.corp.intel.com>
 <20160202094147.GA3778@pd.tnic>
 <20160203104823.GA21257@gmail.com>
 <20160203110052.GA20682@pd.tnic>
 <20160204152235.GB5343@pd.tnic>
 <56B7DAC2.2030506@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56B7DAC2.2030506@zytor.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* H. Peter Anvin <hpa@zytor.com> wrote:

> On 02/04/16 07:22, Borislav Petkov wrote:
> > Here's v2 with the stuff we talked about, implemented. I've added
> > 'control_regs' file too so that you can do:
> > 
> > $ cat /sys/kernel/debug/x86/archinfo/control_regs
> > CR4: [-|-|SMEP|OSXSAVE|-|-|-|-|OSXMMEXCPT|OSFXSR|-|PGE|MCE|PAE|PSE|-|-|-|-]: 0x1406f0
> > 
> > for example. Yeah, only CR4 right now.
> > 
> > Off the top of my head, we would need "msrs" which dumps EFER and a
> > bunch of other interesting MSRs along with the names of the set bits.
> 
> Is there a reason why all this parsing has to be done in kernel space?

Ease of use I suspect, no need to locate some separate utility. Also, no need to 
define an ABI for the information displayed - which keeps things simpler. Since 
it's a kernel module there's no real bloat argument.

Thanks,

	Ingo