All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Christian Nilsson <nikize@gmail.com>
Cc: ipxe-devel@ipxe.org, Michael Brown <mcb30@ipxe.org>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [ipxe-devel] [PATCH ipxe] build: Enable IPv6 for qemu
Date: Thu, 28 Jan 2016 11:19:19 +0100	[thread overview]
Message-ID: <1453976359.30975.39.camel@redhat.com> (raw)
In-Reply-To: <CAHhAHvgJmmS+RXr3F3FJSDy79Ba+PzbV5tdgbyFDSPYpi0PsUw@mail.gmail.com>

  Hi,

> How common is it to build EFI roms, compared to building ipxe.efi or
> snponly.efi?

No idea.  qemu is a very specific case, ipxe has drivers for the qemu
nics (both virtual such as virtio-net and emulated such as rtl8139), and
right now we actually build ipxe tree times (bios, efi-ia32,
efi-x86_64), then combine them into a single image, using EfiRom
(shipped with edk2).  That image is populated to the guest via pci rom
bar.  That way both seabios and ovmf (edk2 firmware for qemu) have
drivers available.

How much bios vs. efi is used -- I don't know.  seabios is the default
and has been for years, so it is pretty clear that seabios takes the
lead.  But whenever uefi share is at 1% or 10% -- no idea.

Probably we'll go add efi-aarch64 roms to the mix once ipxe support is
there, or maybe drop efi-ia32 in favor of efi-aarch64.

> On IRC, roms is quite rare topic compared to non rom builds, but maybe
> that's because those that build roms don't have that many questions.

I suspect it is because it rarely happens.  For onboard nics there
simply is no rom you can easily populate.  Instead the nic rom is stored
in the firmware flash, together with bios/uefi.  Chainloading ipxe.efi
is *alot* simpler than hacking your firmware flash.

Add-on cards are a different story of course, but I suspect >90% of the
use cases are with onboard nics.

The only case where I personally had a ipxe rom running on physical
hardware was when I flashed a T60 Thinkpad (hardware broke meanwhile)
with coreboot.

qemu has a defined set of hardware and prebuilt roms are shipped with
both qemu and distros.  So people rarely have to build qemu roms
themself -> no irc questions either ;)

cheers,
  Gerd

  reply	other threads:[~2016-01-28 10:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-17 17:25 [Qemu-devel] [PATCH ipxe] build: Enable IPv6 for qemu Cole Robinson
2016-01-12 22:18 ` Cole Robinson
2016-01-26 14:21 ` Gerd Hoffmann
2016-01-27 13:06   ` [Qemu-devel] [ipxe-devel] " Michael Brown
2016-01-27 13:49     ` Gerd Hoffmann
2016-01-27 16:39       ` Christian Nilsson
2016-01-28 10:19         ` Gerd Hoffmann [this message]
2016-01-28 16:42           ` Michael Brown
2016-01-28 17:49           ` Laszlo Ersek
2016-01-28 17:50           ` Laszlo Ersek
2016-01-28 11:50     ` Tore Anderson
2016-03-03 12:56     ` Tore Anderson

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=1453976359.30975.39.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=ipxe-devel@ipxe.org \
    --cc=mcb30@ipxe.org \
    --cc=nikize@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.