qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot


From: Michael Brown
Subject: Re: [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot
Date: Mon, 21 Mar 2011 23:14:08 +0000
User-agent: KMail/1.12.2 (Linux/2.6.31.12-desktop-1mnb; KDE/4.3.2; x86_64; ; )

On Monday 21 Mar 2011 21:40:31 Stefan Hajnoczi wrote:
> > Yes, iPXE for UEFI exists and works.  Last tested by me about a week ago,
> > on various IBM UEFI systems.
> >
> > Compared to a "legacy" BIOS network boot, you can't do anything very
> > interesting with UEFI.  Features such as iSCSI, FCoE, AoE, HTTP all work
> > with a "legacy" BIOS but not with UEFI.  A "legacy" BIOS network boot
> > allows you to boot an operating system; a UEFI network boot only allows
> > you to boot an EFI executable (which could be a second-stage OS loader).
> 
> Would it be possible to enable the more interesting things by
> registering as a network device or block device with UEFI?  I don't
> know much about UEFI but I seem to remember that you can do that
> rather than being a pure bootloader that loads an EFI executable?

Yes, and that's what we already do.  Third-party products can, in theory at 
least, use the SNP device provided by an iPXE driver to communicate over the 
network via any protocol that the third-party product wants to implement.

What I meant is that the iSCSI, FCoE, Infiniband, etc. functionality that is 
built in to iPXE and available to a "legacy" BIOS cannot be exposed under 
UEFI.  You need a third-party product which in some cases (e.g. for HTTP boot 
or to use an Infiniband HCA) may not yet exist.

I'm actually quite looking forward to finding a practical use case for UEFI.  
All instances that I've seen so far involve nothing more than adding 
approximately five _minutes_ of initial boot delay before dropping into the 
"legacy" boot environment.

Michael



reply via email to

[Prev in Thread] Current Thread [Next in Thread]