From patchwork Sun Jan 2 15:04:32 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gleb Natapov X-Patchwork-Id: 77188 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 67B21B70A4 for ; Mon, 3 Jan 2011 02:05:42 +1100 (EST) Received: from localhost ([127.0.0.1]:58374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZPV5-0002PP-4F for incoming@patchwork.ozlabs.org; Sun, 02 Jan 2011 10:05:39 -0500 Received: from [140.186.70.92] (port=35737 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZPU9-0002IT-5O for qemu-devel@nongnu.org; Sun, 02 Jan 2011 10:04:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PZPU4-0006GS-EL for qemu-devel@nongnu.org; Sun, 02 Jan 2011 10:04:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PZPU4-0006G5-7Y for qemu-devel@nongnu.org; Sun, 02 Jan 2011 10:04:36 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p02F4YaL021401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 2 Jan 2011 10:04:34 -0500 Received: from dhcp-1-237.tlv.redhat.com (dhcp-1-237.tlv.redhat.com [10.35.1.237]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p02F4XwX018849 for ; Sun, 2 Jan 2011 10:04:34 -0500 Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519) id 00C0718D3EA; Sun, 2 Jan 2011 17:04:32 +0200 (IST) From: Gleb Natapov To: qemu-devel@nongnu.org Date: Sun, 2 Jan 2011 17:04:32 +0200 Message-Id: <1293980672-3515-2-git-send-email-gleb@redhat.com> In-Reply-To: <1293980672-3515-1-git-send-email-gleb@redhat.com> References: <1293980672-3515-1-git-send-email-gleb@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. Subject: [Qemu-devel] [PATCH 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 --- docs/bootindex.txt | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 42 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..9609c7f --- /dev/null +++ b/docs/bootindex.txt @@ -0,0 +1,42 @@ += Bootindex property = + +Block and net devices have bootindex property. This property is used to +determine the order in which firmware will consider devices for booting +guest OS. If 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 command like above firmware should try to boot guest OS from e1000 +NIC if this fails it should try virtio NIC next, if this fails too it +should try virtio disk and then IDE disk. + +== Limitations == + +1. Some firmware has limitation on order in which devices can be +considered for booting. For instance PC bios boot specification allows +only one disk to be bootable. If boot from disk fails for some reason +bios cannot retry booting from other disk. It still can try to boot from +floppy or net though. + +2. Sometimes firmware cannot map device path QEMU wants firmware to boot +from to boot method. It doesn't happen for devices firmware can natively +boot from, but if firmware relies on option rom for booting, and same +option rom is used for booting from more then one device, firmware may +not be able to ask option rom to boot from particular device reliably. +For instance with PC bios if scsi HBA has three bootable devices target1, +target3, target5, connected to it option rom will create boot method for +each of them, but it is not possible to map boot method back to specific +target. This is a shortcoming of PC bios boot specification.