linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
	x86@kernel.org, Borislav Petkov <bp@suse.de>,
	Ingo Molnar <mingo@kernel.org>
Cc: Len Brown <len.brown@intel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	linux-kernel@vger.kernel.org, Andy Lutomirski <luto@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	"Peter Zijlstra \(Intel\)" <peterz@infradead.org>,
	Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Subject: Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs
Date: Sat, 03 Oct 2020 03:39:29 +0200	[thread overview]
Message-ID: <87r1qgccku.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20201002201931.2826-1-ricardo.neri-calderon@linux.intel.com>

On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote:
> Add support to discover and enumerate CPUs in Intel hybrid parts. A hybrid
> part has CPUs with more than one type of micro-architecture. Thus, certain
> features may only be present in a specific CPU type.
>
> It is useful to know the type of CPUs present in a system. For instance,
> perf may need to handle CPUs differently depending on the type of micro-
> architecture. Decoding machine check error logs may need the additional
> micro-architecture type information, so include that in the log.

'It is useful' as justification just makes me barf.

> A hybrid part can be identified by reading a new CPUID feature bit.
> Likewise, CPUID contains information about the CPU type as well as a new
> native model ID. Details can be found in the Intel manual (SDM, [1]).
>
> This series adds support for Intel hybrid parts in two areas: a) adding
> the hybrid feature bit as well as struct cpuinfo_x86; and b) decode machine
> check errors on hybrid parts.

Bla, bla, bla.

> A later submission will use the proposed functionality to expose the CPU
> topology to user space.

The only patch which is accepted for now is:

    	if (boot_cpu_has(X86_FEATURE_HYBRID_CPU))
        	panic("Unsuppported insanity\n");

I'm not all all willing to take anything else unless you or someone else
provides a reasonable explanation for the overall approach of supporting
this mess inlcuding stable kernels.

This has been clearly communicated years ago when the topic was
discussed at one of the Intel Techday events. It's not my problem if
Intel internal communication is disfunctional.

Just to bring you up to speed:

     1) The whole CPU enumeration of x86 sucks and is in no way prepared
        to deal with heterogenous CPU faetures

        Boris and I have discussed this with Intel and on LKML and there
        are ideas how to clean up that mess.

        This needs to be solved first before we even start to talk about
        this CPU has FOO but the other does not.

     2) Intel has been told clearly that a prerequisite of adding any of
        this is a well defined programming model and a proper design of
        dealing with it at the kernel level.

        Since that discussion at one of the Intel events I haven't heard
        and seen anything related to that.

        If Intel thinks that some magic PDF and some Intel internal
        'works for me' patches are solving it, then I just have to give
        up because explaining the requirements again is just waste of
        time.

So I'm taking Patch 1/3 which defines the misfeature flag and then put
something like the above on top which will prevent booting on any of
these machines.

These two patches are going to be marked for stable simply because any
attempt to use any of these asymetric features is a recipe to
disaster. And that disaster is going to happen simply because user space
can use CPUID to figure out what a CPU supports. I'm not at all
interested in the resulting wreckage reports.

It's a sad state of affairs that the only outcome of a dicsussion which
touched all of the above is a patch set which paves the path to hell.

Not going to happen.

Thanks,

        tglx



  parent reply	other threads:[~2020-10-03  1:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 20:19 Ricardo Neri
2020-10-02 20:19 ` [PATCH 1/3] x86/cpufeatures: Enumerate hybrid CPU feature bit Ricardo Neri
2020-10-02 20:19 ` [PATCH 2/3] x86/cpu: Describe hybrid CPUs in cpuinfo_x86 Ricardo Neri
2020-10-02 20:34   ` Borislav Petkov
2020-10-02 21:02     ` Ricardo Neri
2020-10-02 21:03       ` Borislav Petkov
2020-10-02 23:41         ` Ricardo Neri
2020-10-02 20:19 ` [PATCH 3/3] x86/mce: include type of core when reporting a machine check error Ricardo Neri
2020-10-03  1:39 ` Thomas Gleixner [this message]
2020-10-03  2:17   ` [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs Luck, Tony
2020-10-03  9:04     ` Borislav Petkov
2020-10-06  0:24       ` Ricardo Neri
2020-10-03 10:46     ` Thomas Gleixner
2020-10-03 14:39       ` Peter Zijlstra
2020-10-06  0:21       ` Ricardo Neri

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=87r1qgccku.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=bp@suse.de \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=ricardo.neri-calderon@linux.intel.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --subject='Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).