From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TODFT-00074z-7p for qemu-devel@nongnu.org; Tue, 16 Oct 2012 15:56:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TODFS-0007iZ-4D for qemu-devel@nongnu.org; Tue, 16 Oct 2012 15:56:19 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:33787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TODFS-0007iV-0F for qemu-devel@nongnu.org; Tue, 16 Oct 2012 15:56:18 -0400 Received: from /spool/local by e4.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 16 Oct 2012 15:56:17 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 5182338C806A for ; Tue, 16 Oct 2012 15:55:42 -0400 (EDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9GJtfQC173124 for ; Tue, 16 Oct 2012 15:55:41 -0400 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9GJtPWP004878 for ; Tue, 16 Oct 2012 13:55:25 -0600 From: Anthony Liguori Date: Tue, 16 Oct 2012 14:55:21 -0500 Message-ID: <87wqyqyyxi.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] nvram and boot order List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: David Gibson , Alex Graf , Avik Sil We discussed nvram and it's interaction with boot order in today's KVM call. Here's the outcome. This list is completely incremental so it's fine to start with 1-4, for instance, as long as we eventually get to 6. Today, on x86, we implement up to (5) but we don't persist NVRAM. 1) We should modify QEMUMachine to specify that a machine does not want a default boot order. Ideally, this would be done by adding a new default_boot_order that is set to "cad" explicitly in all machines allowing a machine to remove that entry. At any rate, this allows a machine to receive a NULL boot order when -boot isn't used and take an appropriate action accordingly. 2) In the absence of a persistent NVRAM, a ephemeral NVRAM should be generated with a reasonable default boot order. 3) In the absence of -boot or ,bootindex=, the system should boot from order specified in NVRAM. 4) If -boot is specified, the parameter should alter the contents of NVRAM to change the boot order to what is specified by -boot. 5) If ,bootorder is specified, it should take predence over -boot. 6) ,bootorder= should also alter the contents of NVRAM to determine the boot order. Regards, Anthony Liguori