[Qemu-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Qemu-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Cole Robinson]

---
I assume it's fine to enable...

A fedora user requested it here:
https://bugzilla.redhat.com/show_bug.cgi?id=1280318

 src/config/qemu/general.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/config/qemu/general.h b/src/config/qemu/general.h
index 30f60d3..61d0ad4 100644
--- a/src/config/qemu/general.h
+++ b/src/config/qemu/general.h
@@ -8,3 +8,6 @@
 
 /* Work around missing EFI_PXE_BASE_CODE_PROTOCOL */
 #define EFI_DOWNGRADE_UX
+
+/* Enable IPv6 */
+#define NET_PROTO_IPV6
-- 
2.5.0

Re: [Qemu-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Cole Robinson]

On 11/17/2015 12:25 PM, Cole Robinson wrote:
> ---
> I assume it's fine to enable...
> 
> A fedora user requested it here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1280318
> 
>  src/config/qemu/general.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/config/qemu/general.h b/src/config/qemu/general.h
> index 30f60d3..61d0ad4 100644
> --- a/src/config/qemu/general.h
> +++ b/src/config/qemu/general.h
> @@ -8,3 +8,6 @@
>  
>  /* Work around missing EFI_PXE_BASE_CODE_PROTOCOL */
>  #define EFI_DOWNGRADE_UX
> +
> +/* Enable IPv6 */
> +#define NET_PROTO_IPV6
> 

ping, is there any reason IPv6 shouldn't be enabled for qemu?

Thanks,
Cole

Re: [Qemu-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Gerd Hoffmann]

On Di, 2015-11-17 at 12:25 -0500, Cole Robinson wrote:
> ---
> I assume it's fine to enable...
> 
> A fedora user requested it here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1280318

Ping?

What is the reason for ipv6 not being enabled by default?
Just historical?
Rarely used in practice?
ROM image size issues?
Stability concerns?

From qemu point of view this change is fine.
ROM becomes slightly larger (~15k), but that isn't a problem.

thanks,
  Gerd

Re: [Qemu-devel] [ipxe-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Michael Brown]

On 26/01/16 14:21, Gerd Hoffmann wrote:
>> A fedora user requested it here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1280318
>
> Ping?
>
> What is the reason for ipv6 not being enabled by default?
> Just historical?
> Rarely used in practice?
> ROM image size issues?
> Stability concerns?
>
>  From qemu point of view this change is fine.
> ROM becomes slightly larger (~15k), but that isn't a problem.

ROM image size concerns.

I've been thinking for some time now that it would be useful to have a 
"minimal" configuration used for building real BIOS option ROM images 
and a "normal" configuration for everything else (undionly.kpxe, 
ipxe.efi, UEFI ROMs, qemu ROMs, etc).  There are several features that 
are sufficiently commonly used that it would be worth having them 
generally available in the default binaries, but which are currently 
disabled by default due to BIOS ROM size concerns.

We already have the named config mechanism.  I wonder if building a BIOS 
option ROM for a real NIC is sufficiently specialised that it would make 
sense to have a CONFIG=rom or CONFIG=minimal named configuration.

Thoughts from anyone?

Michael

Re: [Qemu-devel] [ipxe-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Gerd Hoffmann]

  Hi,

> We already have the named config mechanism.  I wonder if building a BIOS 
> option ROM for a real NIC is sufficiently specialised that it would make 
> sense to have a CONFIG=rom or CONFIG=minimal named configuration.

Maybe name the configs "rom64k" or "rom128k", to make clear they are
stripped down to keep the size below a certain limit?

cheers,
  Gerd

Re: [Qemu-devel] [ipxe-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Christian Nilsson]

On Wed, Jan 27, 2016 at 2:49 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>   Hi,
>
>> We already have the named config mechanism.  I wonder if building a BIOS
>> option ROM for a real NIC is sufficiently specialised that it would make
>> sense to have a CONFIG=rom or CONFIG=minimal named configuration.
>
> Maybe name the configs "rom64k" or "rom128k", to make clear they are
> stripped down to keep the size below a certain limit?
>
> cheers,
>   Gerd

How common is it to build EFI roms, compared to building ipxe.efi or
snponly.efi?
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.
My preferred default would be IPv6 enabled for EFI but not PCBIOS, but
focus on the most frequent build/usecase.

Adding "rom64k" and "rom128k" sounds like a good basics to then
disable features from the normal?

/Christian

Re: [Qemu-devel] [ipxe-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Gerd Hoffmann]

  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

Re: [Qemu-devel] [ipxe-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Michael Brown]

On 28/01/16 10:19, Gerd Hoffmann wrote:
> 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).

Slightly off-topic: you can do the combining using iPXE's own 
util/catrom.pl:

   ./util/catrom.pl bin/8086100e.mrom \
                    bin-x86_64-efi/8086100e.efirom \
                    bin-i386-efi/8086100e.efirom \
        > efi-e1000.rom

Michael

Re: [Qemu-devel] [ipxe-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Laszlo Ersek]

On 01/28/16 11:19, Gerd Hoffmann wrote:
>   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 ;)

I think that enabling IPv6 for the CONFIG=qemu build of iPXE will have
no effect for OVMF guests.

With CONFIG=qemu we only request SNP interfaces (low level NIC drivers)
from iPXE. Internet protocols are at a higher level, and with
CONFIG=qemu, the edk2 network stack is used on top of iPXE's SNP
interface. The iPXE feature test macro NET_PROTO_IPV6 will have no effect.

OVMF can pull in the IPv6 parts of edk2, but it needs

  -D NETWORK_IP6_ENABLE

for that (<https://github.com/tianocore/edk2/commit/36c6413f76e5>).

Thanks
Laszlo

Re: [Qemu-devel] [ipxe-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Laszlo Ersek]

Sorry, Cole disappeared from the address list, and I forgot to re-add
him. Resending.

On 01/28/16 11:19, Gerd Hoffmann wrote:
>   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 ;)

I think that enabling IPv6 for the CONFIG=qemu build of iPXE will have
no effect for OVMF guests.

With CONFIG=qemu we only request SNP interfaces (low level NIC drivers)
from iPXE. Internet protocols are at a higher level, and with
CONFIG=qemu, the edk2 network stack is used on top of iPXE's SNP
interface. The iPXE feature test macro NET_PROTO_IPV6 will have no effect.

OVMF can pull in the IPv6 parts of edk2, but it needs

  -D NETWORK_IP6_ENABLE

for that (<https://github.com/tianocore/edk2/commit/36c6413f76e5>).

Thanks
Laszlo

Re: [Qemu-devel] [ipxe-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Tore Anderson]

* Michael Brown

> ROM image size concerns.
> 
> I've been thinking for some time now that it would be useful to have
> a "minimal" configuration used for building real BIOS option ROM
> images and a "normal" configuration for everything else
> (undionly.kpxe, ipxe.efi, UEFI ROMs, qemu ROMs, etc).  There are
> several features that are sufficiently commonly used that it would be
> worth having them generally available in the default binaries, but
> which are currently disabled by default due to BIOS ROM size concerns.
> 
> We already have the named config mechanism.  I wonder if building a
> BIOS option ROM for a real NIC is sufficiently specialised that it
> would make sense to have a CONFIG=rom or CONFIG=minimal named
> configuration.
> 
> Thoughts from anyone?

This makes a lot of sense to me. It is a shame that the default builds
of images meant for chain-loading are lacking many of the bells and
whistles. It seems sensible to me to let space-constrained builds
explicitly disable features in order to sufficiently shrink the image,
rather than allowing them to force a "lowest common denominator"
default set on features on all builds.

The lack of default IPv6 support in ipxe.efi is complicating the IPv6
migration for us. Not that it is particularly difficult to build and
distribute our own iPXE images, but it had been much more convenient if
we could use the distribution packages. It's just one more hoop that'd
we'd rather we didn't have to jump through.

It would be nice to have IPv6 support in the default undionly.kpxe too,
but it is less of an issue there as non-UEFI hardware generally
requires IPv4 to be present in the first place.

Tore

Re: [Qemu-devel] [ipxe-devel] [PATCH ipxe] build: Enable IPv6 for qemu

[Tore Anderson]

* Michael Brown <mcb30@ipxe.org>

> I've been thinking for some time now that it would be useful to have a 
> "minimal" configuration used for building real BIOS option ROM images 
> and a "normal" configuration for everything else (undionly.kpxe, 
> ipxe.efi, UEFI ROMs, qemu ROMs, etc).  There are several features that 
> are sufficiently commonly used that it would be worth having them 
> generally available in the default binaries, but which are currently 
> disabled by default due to BIOS ROM size concerns.
> 
> We already have the named config mechanism.  I wonder if building a BIOS 
> option ROM for a real NIC is sufficiently specialised that it would make 
> sense to have a CONFIG=rom or CONFIG=minimal named configuration.

Hi Michael,

Just adding another ping here...

Keeping in mind the «perfect is the enemy of good» mantra, I'm curious:
are there any issues/problems with applying the suggested patch to
enable IPv6 for qemu, and implementing the improved minimal/rom/normal
distinction you're describing at a later time?

Would it be helpful to you if this patch was re-posted a GH pull
request instead of to the mailing list as was originally done?

Best regards,
Tore Anderson