mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Feng Tang <feng.tang@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Dave Hansen <dave.hansen@intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	nivedita@alum.mit.edu, thomas.lendacky@amd.com,
	yazen.ghannam@amd.com, wei.huang2@amd.com
Subject: Re: [RFC PATCH v3] tools/x86: add kcpuid tool to show raw CPU features
Date: Thu, 19 Nov 2020 21:50:10 +0800	[thread overview]
Message-ID: <20201119135010.GC112648@shbuild999.sh.intel.com> (raw)
In-Reply-To: <20201119091815.GA3769@zn.tnic>

On Thu, Nov 19, 2020 at 10:18:15AM +0100, Borislav Petkov wrote:
> On Thu, Nov 19, 2020 at 03:20:55PM +0800, Feng Tang wrote:
> > I just tried the patch on one Debian 9 and 2 Ubuntus (16.04 & 20.10) with
> > different gcc versions, and haven't reproduced it yet.
> 
> That's because you're testing in VMs and they have CPUID(4) which baremetal -
> where I am testing - doesn't and I get

That's really odd. I tried on 3 baremetal machines: one Skylake NUC device,
one Xeon E5-2699 and one Xeon E5-2680.

> parse_line: entry
> parse_line: skip comments
> parse_line: index/main leaf, func: 0x5588497d7300
> parse_line: sub 0, leafs: (nil)
> 			^^^^^^

Thanks for the debugging and root causing!

> for leafs for index 4 and thus this is a NUL ptr. And leaf 4 is the test
> range in cpuid.csv.
> 
> Which brings me to another important point: setup_platform_cpuid()
> should not blindly simply look at the two ranges 0 and 0x8000_0000
> but detect whether it is running on baremetal or on a hypervisor and
> depending on which, setup the respective ranges.
> 
> For example, guests would need to scan 0x4, in addition to the above.
> Centaur CPUs have CPUID in the ranges 0xc0000000 and so on.
> 
> But you don't have to implement all CPUID leafs and ranges - just your
> tool should be careful and first detect on what it runs and then scan
> the possible ranges.

Ok, will check more on this.

> And then exit gracefully when it encounters a range which it doesn't
> know and not segfault.

Yes, it needs to consider more possible errors.

> There could be another option which, when set, would go and scan the
> *whole* 32-bit CPUID range to find whether there are some CPUID ranges
> which are not known. Another option because the scan would potentially
> take long time and thus off by default. And so on.
> 
> Here's the patch I've cleaned up and fixed up so far, please continue
> with it.

Thanks! will go with this version.

- Feng

> Thx.
> 
> ---
> >From 244c34532d1596a0e3603683904497847bb26b1c Mon Sep 17 00:00:00 2001
> From: Feng Tang <feng.tang@intel.com>
> Date: Thu, 22 Oct 2020 13:21:23 +0800
> Subject: [PATCH] tools/x86: Add a kcpuid tool to show raw CPU features
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> End users frequently want to know what features their processor
> supports, independent of what the kernel supports.
> 
> /proc/cpuinfo is great. It is omnipresent and since it is provided by
> the kernel it is always as up to date as the kernel. But, it could be
> ambiguous about processor features which can be disabled by the kernel
> at boot-time or compile-time.
> 
> There are some user space tools showing more raw features, but they are
> not bound with kernel, and go with distros. Many end users are still
> using old distros with new kernels (upgraded by themselves), and may
> not upgrade the distros only to get a newer tool.
> 
> So here arise the need for a new tool, which
>   * shows raw CPU features read from the CPUID instruction
>   * will be easier to update compared to existing userspace
>     tooling (perhaps distributed like perf)
>   * inherits "modern" kernel development process, in contrast to some
>     of the existing userspace CPUID tools which are still being developed
>     without git and distributed in tarballs from non-https sites.
>   * Can produce output consistent with /proc/cpuinfo to make comparison
>     easier.
> 
> The CPUID leaf definitions are kept in an .csv file which allows for
> updating only that file to add support for new feature leafs.
> 
> This is based on prototype code from Borislav Petkov
> (http://sr71.net/~dave/intel/stupid-cpuid.c).
> 
>  [ bp: Massage, add #define _GNU_SOURCE to fix implicit declaration of
>    function ‘strcasestr' warning. ]
> 
> Originally-from: Borislav Petkov <bp@alien8.de>
> Suggested-by: Dave Hansen <dave.hansen@intel.com>
> Suggested-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Feng Tang <feng.tang@intel.com>
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Link: https://lkml.kernel.org/r/1603344083-100742-1-git-send-email-feng.tang@intel.com
> ---
>  tools/arch/x86/kcpuid/Makefile  |  24 ++
>  tools/arch/x86/kcpuid/cpuid.csv |  57 +++
>  tools/arch/x86/kcpuid/kcpuid.c  | 623 ++++++++++++++++++++++++++++++++
>  3 files changed, 704 insertions(+)
>  create mode 100644 tools/arch/x86/kcpuid/Makefile
>  create mode 100644 tools/arch/x86/kcpuid/cpuid.csv
>  create mode 100644 tools/arch/x86/kcpuid/kcpuid.c

  reply	other threads:[~2020-11-19 13:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-22  5:21 Feng Tang
2020-11-18 19:15 ` Borislav Petkov
2020-11-19  7:20   ` Feng Tang
2020-11-19  9:18     ` Borislav Petkov
2020-11-19 13:50       ` Feng Tang [this message]
2020-11-19 14:15         ` Borislav Petkov
2020-11-19 14:32           ` Feng Tang

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=20201119135010.GC112648@shbuild999.sh.intel.com \
    --to=feng.tang@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nivedita@alum.mit.edu \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=wei.huang2@amd.com \
    --cc=x86@kernel.org \
    --cc=yazen.ghannam@amd.com \
    /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

Powered by JetHome