linux-kernel - RE: [PATCH v9 0/4] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1611092252540.3501@nanos>
Date:   Wed, 9 Nov 2016 23:21:11 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Andrejczuk, Grzegorz" <grzegorz.andrejczuk@...el.com>
cc:     "mingo@...hat.com" <mingo@...hat.com>,
        "hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
        "bp@...e.de" <bp@...e.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "Daniluk, Lukasz" <lukasz.daniluk@...el.com>,
        "Cownie, James H" <james.h.cownie@...el.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>,
        "Luc, Piotr" <Piotr.Luc@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v9 0/4] Enabling Ring 3 MONITOR/MWAIT feature for Knights
 Landing

On Wed, 9 Nov 2016, Andrejczuk, Grzegorz wrote:

> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx@...utronix.de] 

Can you pretty please use a mail client which does not copy the whole mail
header into the mail body? That's just annoying.

> Sorry we end up in this situation. 
> 
> I have removed PHI from:
> - MSR definition,
> - HWCAP2 bit,
> - X86_CPU_FEATURE
> 
> Making kernel parameter non-phi would require implementing the
> ring3mwait=disable for any other non-ring 0 MWAIT (i.e AMD MWAITX).

No, it would not. Simply because AMD does not yet provide any means to
enable ring3 MWAIT in the kernel and adding this parameter does not require
to implement it at all. There are gazillions of generic kernel parameters
which are only effective on particular systems. They describe a general
feature not a particular implementation.

If that support for AMD gets ever implemented then it definitely wants to
reuse ring3wait and not phiring3mwait and neiter it wants to add
amdF16ring3mwait..

That feature is going to show up on other Intel cpus sooner than later.
Are we supposed to have xeonring3mwait and atomring3mwait command line
options as well?

Can you see how that gets silly very fast?

> My concern is that kernel will have to maintain various non architectural
> model specific stuff in single kernel parameter.

The feature of enabling ring3 mwait is the same whether it's on PHI, xeon,
atom or some AMD model. Why on earth should they use a different parameter?

If you think I'm wrong, then discuss that instead of silently ignoring my
review requests and resending the same stuff over and over. We could have
been done with that thing weeks ago.

Thanks,

	tglx