[MODERATED] Encrypted Message
Jon Masters <[email protected]>
| Newsgroups | org.kernel.lore.historical-speck |
|---|---|
| Message-ID | <[email protected]> |
On 3/4/19 2:30 AM, speck for Greg KH wrote: > On Sun, Mar 03, 2019 at 07:23:22PM -0600, speck for Josh Poimboeuf wrote: >> From: Josh Poimboeuf <[email protected]> >> Subject: [PATCH RFC 1/4] x86/speculation/mds: Add mds=full,nosmt cmdline >> option >> >> Add the mds=full,nosmt cmdline option. This is like mds=full, but with >> SMT disabled if the CPU is vulnerable. >> >> Signed-off-by: Josh Poimboeuf <[email protected]> >> --- >> Documentation/admin-guide/hw-vuln/mds.rst | 3 +++ >> Documentation/admin-guide/kernel-parameters.txt | 6 ++++-- >> arch/x86/kernel/cpu/bugs.c | 10 ++++++++++ >> 3 files changed, 17 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst >> index 1de29d28903d..244ab47d1fb3 100644 >> --- a/Documentation/admin-guide/hw-vuln/mds.rst >> +++ b/Documentation/admin-guide/hw-vuln/mds.rst >> @@ -260,6 +260,9 @@ time with the option "mds=". The valid arguments for this option are: >> >> It does not automatically disable SMT. >> >> + full,nosmt The same as mds=full, with SMT disabled on vulnerable >> + CPUs. This is the complete mitigation. > > While I understand the intention, the number of different combinations > we are "offering" to userspace here is huge, and everyone is going to be > confused as to what to do. If we really think/say that SMT is a major > issue for this, why don't we just have "full" disable SMT? Frankly, it ought to for safety (can't be made safe). The reason cited for not doing so (Thomas and Linus can speak up on this part) was upgrades vs new installs. The concern was not to break existing folks by losing half their logical CPU count when upgrading a kernel. Jon. -- Computer Architect | Sent with my Fedora powered laptop
(unnamed)
(text/rfc822-headers, 110 B)
From: Jon Masters <[email protected]> To: speck for Greg KH <[email protected]> Subject: Re: [PATCH RFC 1/4] 1