From patchwork Sun Jan 30 10:29:19 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gleb Natapov X-Patchwork-Id: 81011 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 460741007D1 for ; Sun, 30 Jan 2011 21:32:06 +1100 (EST) Received: from localhost ([127.0.0.1]:44612 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjUZg-0004PT-3A for incoming@patchwork.ozlabs.org; Sun, 30 Jan 2011 05:32:04 -0500 Received: from [140.186.70.92] (port=33505 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjUX6-0003Vz-PQ for qemu-devel@nongnu.org; Sun, 30 Jan 2011 05:29:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PjUX5-0004SI-AB for qemu-devel@nongnu.org; Sun, 30 Jan 2011 05:29:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PjUX5-0004Rx-1G for qemu-devel@nongnu.org; Sun, 30 Jan 2011 05:29:23 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0UATKQV014347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 30 Jan 2011 05:29:21 -0500 Received: from dhcp-1-237.tlv.redhat.com (dhcp-1-237.tlv.redhat.com [10.35.1.237]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p0UATJ1V005060 for ; Sun, 30 Jan 2011 05:29:20 -0500 Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519) id 51AA018D3EA; Sun, 30 Jan 2011 12:29:19 +0200 (IST) From: Gleb Natapov To: qemu-devel@nongnu.org Date: Sun, 30 Jan 2011 12:29:19 +0200 Message-Id: <1296383359-19082-2-git-send-email-gleb@redhat.com> In-Reply-To: <1296383359-19082-1-git-send-email-gleb@redhat.com> References: <1296383359-19082-1-git-send-email-gleb@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCHv2 2/2] Add boot index documentation. X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Signed-off-by: Gleb Natapov --- docs/bootindex.txt | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 43 insertions(+), 0 deletions(-) create mode 100644 docs/bootindex.txt diff --git a/docs/bootindex.txt b/docs/bootindex.txt new file mode 100644 index 0000000..16083b3 --- /dev/null +++ b/docs/bootindex.txt @@ -0,0 +1,43 @@ += Bootindex propery = + +Block and net devices have bootindex property. This property is used to +determine the order in which firmware will consider devices for booting +the guest OS. If the bootindex property is not set for a device, it gets +lowest boot priority. There is no particular order in which devices with +unset bootindex property will be considered for booting, but they will +still be bootable. + +== Example == + +Lets assume we have QEMU machine with two NICs (virtio, e1000) and two +disks (IDE, virtio): + +qemu -drive file=disk1.img,if=none,id=disk1 + -device ide-drive,drive=disk1,bootindex=4 + -drive file=disk2.img,if=none,id=disk2 + -device virtio-blk-pci,drive=disk2,bootindex=3 + -netdev type=user,id=net0 -device virtio-net-pci,netdev=net0,bootindex=2 + -netdev type=user,id=net1 -device e1000,netdev=net1,bootindex=1 + +Given the command above, firmware should try to boot from the e1000 NIC +first. If this fails, it should try the virtio NIC next, if this fails +too, it should try the virtio disk, and then the IDE disk. + +== Limitations == + +1. Some firmware has limitations on which devices can be considered for +booting. For instance, the PC BIOS boot specification allows only one +disk to be bootable. If boot from disk fails for some reason, the BIOS +won't retry booting from other disk. It still can try to boot from +floppy or net, though. + +2. Sometimes, firmware cannot map the device path QEMU wants firmware to +boot from to a boot method. It doesn't happen for devices the firmware +can natively boot from, but if firmware relies on an option ROM for +booting, and the same option ROM is used for booting from more then one +device, the firmware may not be able to ask the option ROM to boot from +a particular device reliably. For instance with PC BIOS, if a SCSI HBA +has three bootable devices target1, target3, target5 connected to it, +the option ROM will have a boot method for each of them, but it is not +possible to map from boot method back to a specific target. This is a +shortcoming of PC BIOS boot specification.