Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1835409imm; Thu, 23 Aug 2018 09:30:44 -0700 (PDT) X-Google-Smtp-Source: AA+uWPy72iUEIIjd9/gVU7gCIZO/IQpAYheRzI5Hud7KUbRSKs0RgBmxDQU2VQf77Xbi/myLvSvo X-Received: by 2002:a63:5a50:: with SMTP id k16-v6mr20235836pgm.143.1535041843946; Thu, 23 Aug 2018 09:30:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535041843; cv=none; d=google.com; s=arc-20160816; b=Nt5oq1pIZ37gUze5fBn5h54+E1aq0ADmrNwH5vUG+4g+cd16GVgVEeqeu6igG916wG 2yqtLCfUp2NW2iT2F724/dG6NiX1bU6KyD1RfELmrkKtOCgYwiGznFO66Gbe+TNTSL1x Pp1Kx3gmwxGkNaw9+3rgGb64qeEaNSr/dx/BHyfeAfT5l1zJLTJeBIBCOhSVre3y/fe0 DbnBBwOVFvSUheg3/WGWRBKaAayRMpu1FaBMLyxssAFUsPUxWL6J2GFD8qLZIqJsXt61 5yvmylOI6n8OCL9KAy30kVHubaacNj+n4oickKg/lzKYXDBzffwSVA14F5wbnWxHBbEj vtHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=q/1H5ANYD1H3XQj9F6Vm4L5W5kLPN01RGZTANepmgks=; b=PkP//oUm/ZU7605YNqLAVoKXsxu/VSxSaxkVVHvDmi+/lNZ3tLcHkEZcIjeB3BfdKS ol8VGX09+sHzetozuDdqlV7l6fJb96mtAL/gnzysZyZh0CGJTVg29MgnPPZkLRLQrCJB IIIFHZA1J4eGleEAgHT+kxjJaD0ncEg2SZVxdD28CBy5TOfiOaTNOCeRFpXWWt7C7HsZ d1zXYGLEdOTjTBy7W1VliXREC+q7vMr3gTVC5FSaXQspX1Lo/zFuycFx39lxkXlVJGSd HHZVveZaHChBSqlkbVOpDKtbD1DrCbEIkCn82aM+uiKpm9+YbI4b8I46Om1vhERrQaGl 7S2Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c16-v6si5176831pfj.333.2018.08.23.09.30.28; Thu, 23 Aug 2018 09:30:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728361AbeHWTRC (ORCPT + 99 others); Thu, 23 Aug 2018 15:17:02 -0400 Received: from mga09.intel.com ([134.134.136.24]:64034 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727633AbeHWTRC (ORCPT ); Thu, 23 Aug 2018 15:17:02 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2018 08:46:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,278,1531810800"; d="scan'208";a="83902425" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.126]) by fmsmga001.fm.intel.com with ESMTP; 23 Aug 2018 08:46:48 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id D04E4301B91; Thu, 23 Aug 2018 08:46:48 -0700 (PDT) Date: Thu, 23 Aug 2018 08:46:48 -0700 From: Andi Kleen To: Vlastimil Babka Cc: Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , Dave Hansen , Michal Hocko , stable@vger.kernel.org, Michal Hocko Subject: Re: [PATCH] x86/speculation/l1tf: suggest what to do on systems with too much RAM Message-ID: <20180823154648.GD12066@tassilo.jf.intel.com> References: <20180823134418.17008-1-vbabka@suse.cz> <20180823142812.7363-1-vbabka@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180823142812.7363-1-vbabka@suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 23, 2018 at 04:28:12PM +0200, Vlastimil Babka wrote: > Two users have reported [1] that they have an "extremely unlikely" system > with more than MAX_PA/2 memory and L1TF mitigation is not effective. Let's > make the warning more helpful by suggesting the proper mem=X kernel boot param, > a rough calculation of how much RAM can be lost (not precise if there's holes > between MAX_PA/2 and max_pfn in the e820 map) and a link to the L1TF document > to help decide if the mitigation is worth the unusable RAM. I'm not sure anyone would really do that. After all you probably prefer your memory. And if it's really a non ECC client part they are are already used to to live very dangerously because their undetected RAM bit error rate will be significant. L1TF is probably one of your smaller problems in this case... -Andi