From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com ([134.134.136.65]:9133 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726803AbeHXBjg (ORCPT ); Thu, 23 Aug 2018 21:39:36 -0400 Date: Thu, 23 Aug 2018 15:07:53 -0700 From: Andi Kleen To: Michal Hocko Cc: Vlastimil Babka , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , Dave Hansen , stable@vger.kernel.org Subject: Re: [PATCH] x86/speculation/l1tf: suggest what to do on systems with too much RAM Message-ID: <20180823220753.GG12066@tassilo.jf.intel.com> References: <20180823134418.17008-1-vbabka@suse.cz> <20180823142812.7363-1-vbabka@suse.cz> <20180823154648.GD12066@tassilo.jf.intel.com> <20180823192547.GS29735@dhcp22.suse.cz> <20180823193833.GE12066@tassilo.jf.intel.com> <20180823200520.GW29735@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180823200520.GW29735@dhcp22.suse.cz> Sender: stable-owner@vger.kernel.org List-ID: On Thu, Aug 23, 2018 at 10:05:20PM +0200, Michal Hocko wrote: > On Thu 23-08-18 12:38:33, Andi Kleen wrote: > > > There are people who care about L1TF mitigations. I am not going to > > > question their motivation. In any case a hint how to make the mitigation > > > active again sounds more useful than something that sounds as scary as > > > "you are vulnerable". > > > > FWIW an early version of these patches automatically limited the available > > memory, but Linus pointed out that people likely prefer their memory. > > Nobody is questioning that. The point is to give them a hint on how to > make the mitigation active again without going to call for help. The > message does tell them how to _enable_ it and point them to the > documentation on how to _decide_. On the message I guess there are two cases: - either it's very little memory that is lost like in the 32GB + memory hole case. In this case maybe it's better if we just limit automatically if the overlap is small enough (<2GB perhaps?) - Or it's a lot of memory then people are unlikely to want to lose their memory and I don't think we really need the message either. Also I checked the bug again and it looks like the reporter has an IvyBridge. There is actually a better solution for those (anything Nehalem and newer) because they internally have at least 44 bits in the cache, which is good enough for the mitigation. Just need a quirk to override the bit width in this case (will submit a patch) -Andi