| 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 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
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
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
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
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
* 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
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
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
* 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
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