Hi,
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).
A
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home