Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 19 Jun 2020 18:17:52 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     Andy Lutomirski <luto@amacapital.net>
Cc:     Richard Hughes <hughsient@gmail.com>,
        Daniel Gutson <daniel@eclypsium.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "David S. Miller" <davem@davemloft.net>,
        Rob Herring <robh@kernel.org>, Tony Luck <tony.luck@intel.com>,
        Rahul Tanwar <rahul.tanwar@linux.intel.com>,
        Xiaoyao Li <xiaoyao.li@intel.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Ability to read the MKTME status from userspace
Message-ID: <20200619161752.GG32683@zn.tnic>
References: <CAD2FfiFRqwYGB50KK=aA0sU6uCALYneoyD=V4EfOsk-Ex=C+xg@mail.gmail.com>
 <0DD7FAE4-3976-4835-8090-80B84B737F3E@amacapital.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0DD7FAE4-3976-4835-8090-80B84B737F3E@amacapital.net>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jun 19, 2020 at 08:48:47AM -0700, Andy Lutomirski wrote:
> Boris, it wouldn’t be totally crazy for cpuinfo to learn to
> distinguish between “your platform has this feature but Linux
> isn’t using it” and “your platform doesn’t have this feature
> in the first place”. And I suppose there’s this extra silly state
> “your platform has this feature, but your firmware didn’t enable
> it”. This would be a big job.

Well, I believe all the kernel can do is supply bits of information -
just like MSRs - and depending on the settings of those bits, userspace
can decide what the situation is. For example:

bit 0 - CPUID support
bit 1 - BIOS enabled
bit 2 - quirk applied
bit 3 - microcode fixes present
...

and so on.

It needs a proper definition though and userspace to say, yes, we want
that and that is useful for us.

Where it ends up is then beside the point - /proc/cpuinfo,
/sys/devices/system/cpu, whatever...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette