Message-ID: <87r1qgccku.fsf@nanos.tec.linutronix.de>
Date:   Sat, 03 Oct 2020 03:39:29 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>,
        x86@...nel.org, Borislav Petkov <bp@...e.de>,
        Ingo Molnar <mingo@...nel.org>
Cc:     Len Brown <len.brown@...el.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
        Tony Luck <tony.luck@...el.com>,
        "Peter Zijlstra \(Intel\)" <peterz@...radead.org>,
        Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
Subject: Re: [PATCH 0/3] x86: Add initial support to discover Intel hybrid CPUs

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

Powered by blists - more mailing lists