From: Michael Brown <mbrown@fensystems.co.uk>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Jordan Justen <jljusten@gmail.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot
Date: Mon, 21 Mar 2011 23:14:08 +0000 [thread overview]
Message-ID: <201103212314.09015.mbrown@fensystems.co.uk> (raw)
In-Reply-To: <AANLkTinjSdbizxDk=0MVkiQ26faaZ-waE+wKXTXDYpX2@mail.gmail.com>
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
next prev parent reply other threads:[~2011-03-21 23:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 18:14 [Qemu-devel] OVMF, SeaBIOS & non-CSM based legacy boot Jordan Justen
2011-03-21 18:27 ` Anthony Liguori
2011-03-21 21:06 ` Stefan Hajnoczi
2011-03-21 21:17 ` Michael Brown
2011-03-21 21:31 ` Jordan Justen
2011-03-21 21:40 ` Stefan Hajnoczi
2011-03-21 23:14 ` Michael Brown [this message]
2011-03-21 21:23 ` Jordan Justen
2011-03-22 8:00 ` Gleb Natapov
2011-03-22 19:28 ` Jordan Justen
2011-03-22 20:07 ` Gleb Natapov
2011-03-22 21:53 ` Jordan Justen
2011-03-23 12:36 ` Gleb Natapov
2011-03-23 22:32 ` Jordan Justen
2011-03-24 11:53 ` Gleb Natapov
2011-03-24 16:46 ` Jordan Justen
2011-03-24 18:36 ` Gleb Natapov
2011-03-24 12:27 ` Michal Suchanek
2011-03-24 13:44 ` Gleb Natapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201103212314.09015.mbrown@fensystems.co.uk \
--to=mbrown@fensystems.co.uk \
--cc=jljusten@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).