From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LDLbd-0005Lj-Vj for qemu-devel@nongnu.org; Thu, 18 Dec 2008 11:20:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LDLbc-0005Iy-DI for qemu-devel@nongnu.org; Thu, 18 Dec 2008 11:20:09 -0500 Received: from [199.232.76.173] (port=52908 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LDLbc-0005IS-6q for qemu-devel@nongnu.org; Thu, 18 Dec 2008 11:20:08 -0500 Received: from mx20.gnu.org ([199.232.41.8]:31398) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LDLbb-0001eJ-Rg for qemu-devel@nongnu.org; Thu, 18 Dec 2008 11:20:07 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LDLba-0006XA-2x for qemu-devel@nongnu.org; Thu, 18 Dec 2008 11:20:06 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] x86: Manage BIOS boot menu via command line Date: Thu, 18 Dec 2008 16:20:01 +0000 References: <494A4A55.2090700@siemens.com> In-Reply-To: <494A4A55.2090700@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812181620.01572.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Jan Kiszka On Thursday 18 December 2008, Jan Kiszka wrote: > When booting a guest from the command line, you normally do not need the > interactive boot menu with its 3 s waiting that someone might press F12. > So this patch introduces a mechanism to enable the boot menu only on > demand, ie. when the user provided the command line switch -bootmenu. > This reduces boot times to their original dimension. > > The host-guest interface used here is CMOS RAM byte 0x60. If it is > non-zero, the guest BIOS will skip the F12 delay, keeping the previous > behavior in case the host does not support it. -bootmenu was chosen in > favor of -boot as the syntax of the latter is not easily and cleanly > extensible. I'm not sure I believe this. We already support multiple options to -boot so why not just add another one (e.g. "q") that means include the boot menu? i.e. -boot qcad would give the current behaviour. I've no particular preference whether this is communicated to the bios via the current 0x3d region or via a new byte. It looks like there's a spare bit in byte 0x38 that could be used. Paul