This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH] Replace bios_relocate hook with bios_load ho

To: Keir Fraser <keir.xen@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] Replace bios_relocate hook with bios_load hook in hvmloader
From: Andrei Warkentin <andreiw@xxxxxxxxxxxx>
Date: Wed, 27 Jul 2011 12:55:06 -0500
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jordan Justen <jljusten@xxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>, Bei Guan <gbtju85@xxxxxxxxx>
Delivery-date: Wed, 27 Jul 2011 10:56:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA558C5A.1EA22%keir.xen@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110727080920.GO8970@xxxxxxxxxxxxxxxxxxxxxxx> <CA558C5A.1EA22%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Wed, Jul 27, 2011 at 3:35 AM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 27/07/2011 09:09, "Tim Deegan" <Tim.Deegan@xxxxxxxxxx> wrote:
>> At 08:34 +0100 on 27 Jul (1311755670), Keir Fraser wrote:
>>> By the way, what are the advantages for us of supporting OVMF? I know it
>>> gets us the UEFI support tickybox, but for me that begs the same question.
>>> Why is it useful?

IPv4/IPv6 iSCSI, for example. Larger disk support for booting (GPT vs
MBR). Reducing dependence on I/O emulators for HVM guest bootup, with
the associated speedup by having UEFI use PV drivers for block, net,
console, etc.

>> When Windows boots from UEFI it can load just its system-disk driver via
>> the firmware and the rest of the OS using its own driver; that ought to
>> make Windows boot times much faster.

Not quite. It uses the firmware services (UEFI or BIOS) to do the load
of everything (NT, HAL, registry, drivers). This is easy to test -
disable DMA inside ATAPI driver and see how fast a windows CD boots
from UEFI... After the bootloader  is ready to hand-off, it quiesces
the firmware. To make things faster, you ought to make PV drivers,
although it already could be faster if the ATA/ATAPI drivers use
features not used in legacy ROM.

> That's interesting. Why can't it do that with legacy firmware? Does it need
> to keep the legacy BIOS alive for a while and hence can't use its own
> drivers, or something like that?

Implementing PV drivers in BIOS presents challenges imposed by the
operating environment (16bit RM), additionally, since there is never
an explicit hand-off of HW from firmware to OS, you have no
opportunity for clean-up of PV state (pages, evtchns, etc).


Xen-devel mailing list