Comment 16 for bug 1789319

I may be able to provide some information here, about iPXE. (Corrections welcome, obviously!)

iPXE can be built in a number of ways. Two of those are: (1) as a UEFI *driver* that is presented in a NIC's PCI ROM BAR (i.e., as part of a PCI expansion ROM), (2) as a UEFI *application* that can be loaded from optical media / an ISO image, or a USB flash drive, or chain-loaded over the network with the platform firmware's built-in netboot capabilities.

Independently of that dimension (i.e., build target), iPXE can be built with different features enabled (through feature test macros). One of those feature macros is "EFI_DOWNGRADE_UX". You can read about it e.g. in iPXE commit a15c0d7e868a ("[efi] Allow user experience to be downgraded", 2015-07-22).

I'll spare you the technical details; the point is that without "EFI_DOWNGRADE_UX" (that is, in the default case), iPXE sort of takes over the entire UEFI netboot process, supplanting most of the edk2 network stack (which is built into OVMF).

It is widely agreed upon that this behavior is appropriate for build type (2) above, i.e. when iPXE is launched as a UEFI *application*.

Opinions differ whether this behavior is approprite for build type (1), that is, when iPXE is built as a UEFI *driver*, to be included in a specific NIC's PCI ROM BAR / expansion ROM image.

In my personal opinion, which some others (but definitely not all) share, for build type (1), the "take-over" behavior of iPXE is not desirable, and iPXE should only provide the lowest level hardware driver for the NIC. (And then the rest of the UEFI network stack will come from the edk2 modules -- this is precisely the situation that Steve describes in comment#1.) In other words, for build type (1), the "EFI_DOWNGRADE_UX" feature test macro should be defined -- in my opinion. And, since iPXE commit a200ad462e69 ("[build] Add named configuration for qemu", 2015-07-22), this is easily achievable by passing the "CONFIG=qemu" macro definition to "make", when the "bin-x86_64-efi/*.efidrv" files are built.

From the pics attached earlier (e.g. comment#3), I'm nearly 100% sure that the iPXE UEFI drivers in question -- build type (1) -- had been built *without* EFI_DOWNGRADE_UX. While more recent iPXE commit 3376fa520b0c ("[efi] Implement the EFI_PXE_BASE_CODE_PROTOCOL", 2015-09-02) suggests this should function OK, I would still suggest rebuilding the iPXE UEFI drivers (the PCI oproms) with "CONFIG=qemu", and retrying.

"CONFIG=qemu" is certainly what we use in RHEL and Fedora, in the ipxe-roms-qemu package. It's easy to refer to the Fedora spec file:

https://koji.fedoraproject.org/koji/packageinfo?packageID=13673

One more addition: from comment #2, I see that the NIC device model is virtio. For a virtio NIC, you don't even need that "lowest level hardware driver" to come from iPXE -- OVMF has a built-in (= native to edk2) driver for virtio-net. It's located under OvmfPkg/VirtioNetDxe. This means that, if you want to, you can netboot entirely without iPXE. (Note I'm not saying you "should" boot without iPXE, just that you "can", *if* you want to.) This is how:

As explained in OvmfPkg/README (see "Network Support"), if you use a virtio NIC, and do not prevent QEMU (through the libvirt domain config) from loading the iPXE oprom for the NIC, then iPXE's UEFI driver will take precedence (regardless of whether it was built with or without CONFIG=qemu) over OVMF's built-in driver. Using modern libvirt, you can disable oprom loading (thereby opt for the built-in virtio-net driver) by adding "rom enabled='no'/" under the "interface" element. Using less recent libvirt, "rom bar='off'/" works somewhat similarly, although technically it's quite different, and it won't work if you try to add it to multiple "interface" elements. (Refer to RHBZ#1425058 for details.)

(I'm sorry for not including actual XML fragments -- I don't know if Launchpad gets confused by unescaped angle brackets in comments.)

Summary:

- *If* you think this use case -- i.e., build type (1) -- is worth testing with an iPXE oprom limited to the lowest level hardware driver feature, then I suggest rebuilding iPXE (just the efidrv files) with "CONFIG=qemu" passed on the "make" command line.

- *If* you think this use case -- i.e., build type (1) -- is worth testing with iPXE entirely absent, then I suggest (a) sticking with the virtio NIC, and (b) disabling oprom loading in the libvirt domain XML, preferably with "rom enabled='no'", and less preferably with "rom bar='off'".

(In either of the above two cases, it's still possible to use the super-advanced features of a full-blown iPXE build. For that, build iPXE without CONFIG=qemu (which is the default) for build target (2), i.e., as a UEFI application ("ipxe.efi"), and chain-load that over the network.)