| Message ID | 59b02541da838ce9a0246178deb3c377109589bb.1447780013.git.crobinso@redhat.com |
|---|---|
| State | New |
| Headers | show |
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
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
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
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