Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp58108pxj; Wed, 26 May 2021 16:05:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxcjhMXVuqY4UVhDKR84fZgdU6EdctYr3Prjr/vHYu6Ls0GHG5DbqO9StJ4LNXLhEaMneLt X-Received: by 2002:a05:6e02:4a6:: with SMTP id e6mr568724ils.254.1622070305537; Wed, 26 May 2021 16:05:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622070305; cv=none; d=google.com; s=arc-20160816; b=dgX1fv+33ryDuM7rzjrBD8L/MmnSFAMn2DSi36XunWjOslL/iqx3z4/jMJBwWgbcMl fbJm01Hs93cFqxOG/I60ua5aCUC7vnfqPJZE2atcUEDMQDCWx7ZK26dOIimaztGo3VNP auekU2GM0+xW3xq2+5Ls6Wh7bmNDrk4HSkR6GwGTqaVYAvNLYM6YN9b0klOX2vBHthsR +BXWe+Z93h9kQUWyfzg1dCrmQTUdGfXOMtjTOETCUE9kjTuYDoDZgBZNpkL0GU7LelPe h/BkjokJTIh9i8Yi7eodDoszhOsSkWsxBDKBhuLTn2nR1TfkMk6RBRqYd5ekjVtYcHjz RN2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=3xmEF/K2LnnBVy6PxdIzYYp3iPIXDRA9mR275WMcJO8=; b=g4rArHVjwBzbMRa3KhW/eT7E9ibzA/1+OHlwYvsez1m9jjA4zFCZnjht3pmzjDlccE zve1rzmpQV1HApLHwcg1EkLUNj6FvvBCIGFtPbF+Qlvp3VTnBWUDZWT5/tlDC6UZW8LH rpWTvBzJyFCxO1VA96SNtQYesH0Fmy4Atly4TevdJRmALb0D8VRX9c4bL7eqo0Wsnl5z G1syA1SfQxvTZffOFEKfML3e7BeST3XpXfU9ico8oSf7SvtX+sZS7NWAhx5vk1kOvkC9 dVNND5jY3puZ5vY+QglgRRd/vLl3GlEnrdsbWPom1DnBLf7SPzKAKlr/48tcLZVv6Hm6 iTXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=rvLwmmyU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k43si644554jav.84.2021.05.26.16.03.57; Wed, 26 May 2021 16:05:05 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=rvLwmmyU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234996AbhEZSQ2 (ORCPT + 99 others); Wed, 26 May 2021 14:16:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232870AbhEZSQ1 (ORCPT ); Wed, 26 May 2021 14:16:27 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E880CC061574 for ; Wed, 26 May 2021 11:14:55 -0700 (PDT) Received: from zn.tnic (p200300ec2f0d4900a10086c04c57b79b.dip0.t-ipconnect.de [IPv6:2003:ec:2f0d:4900:a100:86c0:4c57:b79b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id F13821EC04A6; Wed, 26 May 2021 20:14:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1622052891; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=3xmEF/K2LnnBVy6PxdIzYYp3iPIXDRA9mR275WMcJO8=; b=rvLwmmyUWDzwJfROcttctvb+E29HyIstvseDmjy4W9/zCYDr7AuHy6cH5n62EYwZ1/+jZ6 bYhfV42XmOd1Y01Ve2wf1CxB4ZkZOvXNf3VRHsYpdVCWi7oP4pyajuC+fprVlCTRzCYsPK ftyA3UhWe3ZapYdAKTGUO+C4nPLDe1A= Date: Wed, 26 May 2021 20:14:44 +0200 From: Borislav Petkov To: Mike Rapoport Cc: Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Mike Rapoport , untaintableangel@hotmail.co.uk, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/Kconfig: decrease maximum of X86_RESERVE_LOW to 512K Message-ID: References: <20210526081100.12239-1-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 26, 2021 at 07:30:09PM +0300, Mike Rapoport wrote: > We can restore that behaviour, but it feels like cheating to me. We let > user say "Hey, don't touch low memory at all", even though we know we must > use at least some of it. And then we sneak in an allocation under 640K > despite user's request not to use it. Sure but how are we going to tell the user that if we don't sneak that allocation, we won't boot at all. I believe user would kinda like the box to boot still, no? :-) Yeah, you have that now: + Note, that a part of the low memory range is still required for + kernel to boot properly. but then why is 512 ok? And why was 640K the upper limit? Looking at: d0cd7425fab7 ("x86, bios: By default, reserve the low 64K for all BIOSes") and reading that bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=16661 it sounds like it is the amount of memory where BIOS could put crap in. Long story short, we reserve the first 64K by default so if someone reserves the total range of 640K the early code could probably say something like "adjusting upper reserve limit to X for the real-time trampoline" when the upper limit is too high so that a trampoline can't fit... Which is basically what your solution does... But then the previous behavior used to work everywhere so if it is only cheating, I don't mind doing that as long as boxes keep on booting. Or am I missing an aspect? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette