Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3709042imu; Sun, 11 Nov 2018 22:04:29 -0800 (PST) X-Google-Smtp-Source: AJdET5eEiuExPOwpmiwPiEYeUwiQ5soH3APw2/s2FeQNDWvDohAOcfBzLreN/tfZUbYrwisaKD7l X-Received: by 2002:a62:1416:: with SMTP id 22-v6mr19081147pfu.114.1542002669321; Sun, 11 Nov 2018 22:04:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542002669; cv=none; d=google.com; s=arc-20160816; b=fYhxNS53mutziFvIgnT0zEoCX0gVifQdPfnYldXslK9RwpR9El6uM8bZRN/FsSZU8L wtxt4Br3e2I+OU3NP990Jy/+w7ccRJ8sj30qxca2T2EyQ57/nGX8MAcoQ/MqaWDh04IC h747kEx48WS5I0byvMTpknfCx2Kk0i1+l2oErXm8BA6zC79EqFvVl2TpMzTJaCO4pv1K 9wCXSSNy/ODVdirHzP9xB2GkiBhPJdhb28N3SQBlfCu4S0+5RDy4Uubo9x8Lm4VWELRO BXucTzp3zTcbw0TtxibssuEWPnlzwNqzkgQ73BpoCbwRsbcBWg8PLXUp5D3HDqPMMBty 59SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=7Iknx6UhWEIxfO2/TWzkSrRrGr7SVunCoqg9/dIb6JE=; b=b7HCOLqI+dwRwhCdkxkd+cRVeXL3ZMhpLdMq3DSkh3noyIXneTZSNri0G2W2qFVJpK YQRWwys2UKeB+PNc06IgJAEAOPAVUJJXuuPkod6yYpYSYRqBzvBbgE3EZ8/UImftYKq7 JFYQmSMadBJw9N8W3648OgC/lNvAo2tKMPbs8wEM6eBR2piR+q8XLFriS5JPQEUPueLd ecLphskZROEIJQKs22onQ0IUmgFoQuSKXGeclV5v66gD5Z+wRhRFLaLnql9dGVKYMc+o 8P3d+34lpuLaj7AvJOQLktWf78USRJBHn8RooSVL0qdIuZZG1eXIvG+Cc/hpQyOvdYJ9 6W/A== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y2si14802789pgl.148.2018.11.11.22.04.14; Sun, 11 Nov 2018 22:04:29 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731801AbeKLPx4 (ORCPT + 99 others); Mon, 12 Nov 2018 10:53:56 -0500 Received: from terminus.zytor.com ([198.137.202.136]:51741 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731226AbeKLPxz (ORCPT ); Mon, 12 Nov 2018 10:53:55 -0500 Received: from carbon-x1.hos.anvin.org (c-24-5-245-234.hsd1.ca.comcast.net [24.5.245.234] (may be forged)) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id wAC60lUC3546540 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 11 Nov 2018 22:00:47 -0800 Subject: Re: [Qemu-devel] [RFC/PoC PATCH 1/3] i386: set initrd_max to 4G - 1 to allow up to 4G initrd To: Ingo Molnar Cc: Li Zhijian , Juergen Gross , Li Zhijian , Peter Maydell , x86@kernel.org, bp@alien8.de, mingo@redhat.com, tglx@linutronix.de, QEMU Developers , Philip Li , linux-kernel@vger.kernel.org, Linus Torvalds , Peter Zijlstra , Kees Cook References: <1541674784-25936-1-git-send-email-lizhijian@cn.fujitsu.com> <1541674784-25936-2-git-send-email-lizhijian@cn.fujitsu.com> <20181109072015.GA86700@gmail.com> <38905d35-29af-b522-1629-b13e98a47a42@intel.com> <20181112045624.GA28219@gmail.com> From: "H. Peter Anvin" Message-ID: Date: Sun, 11 Nov 2018 22:00:42 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181112045624.GA28219@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/11/18 8:56 PM, Ingo Molnar wrote: > >> Also note that the ext_ramdisk_image and ext_ramdisk_size are part of >> struct boot_params as opposed to struct setup_header, which means that >> they are not supported when entering via the 16-bit BIOS entry point, >> and I am willing to bet that there will be, ahem, "strangeness" if >> entered via the 32-bit entry point if at least the command line is >> loaded above the 4 GB mark; the initrd should be fine, though. >> >> This is obviosly not an issue in EFI environments, where we enter >> through the EFI handover entry point. >> >> The main reason these were not added to struct setup_header is that >> there are only 24 bytes left in that header and so space is highly >> precious. One way to deal with that if we really, really need to would >> be to add an initrd/initramfs type of setup_data. > > Is there no way to extend that header by making an extended header part > of the payload? > > IIRC that header is small and fixed size to be part of a single sector at > the very beginning of boot images, but accessing any extended header bits > from the payload section shouldn't really be an issue for a modern > bootloader to handle, right? > > Such an extended header could use a more modern (self-extending) ABI as > well. > Yes, although I don't really think it is as much of an issue as it seems at this point. The limit comes from having used a one-byte jump instruction at the beginning; however, these days that limit is functionally walled. It is of course possible to address this if it should become necessary, however, the current protocol has lasted for 23 years so far and we haven't run out yet, even with occasional missteps. As such, I don't think we are in a huge hurry to address this particular aspect. In part as a result of this exchange I have spent some time thinking about the boot protocol and its dependencies, and there is, in fact, a much more serious problem that needs to be addressed: it is not currently possible in a forward-compatible way to map all data areas that may be occupied by bootloader-provided data. The kernel proper has an advantage here, in that the kernel will by definition always be the "owner of the protocol" (anything the kernel doesn't know how to map won't be used by the kernel anyway), but it really isn't a good situation. So I'm currently trying to think up a way to make that possible. -hpa