Networking in OVMF doesn't seem to work by default (in more recent tags)

[AndrewFalanga]

I have been developing for networking and ran into a stiff wall. The network stack wasn't loading. From the shell, when I use pci I can see an Intel 82574l 1Gb NIC and drivers shows 808610d3.efidrv (from iPXE) is loaded as expected. The problem however is that none of the network stack is loaded, e.g. TcpDxe and the rest.

I asked for some insights on SO. Using pointers from the respondent on that thread I've learned that the problem seemed to creep into the code base between edk2-stable202402 and edk2-stable202405. I can build OVMF with the Feb 2024 tag and the VM tries to do a PXE boot and the full network stack is loaded. (This is verified by drivers -b showing things like TcpDxe, HttpDxe, etc.) However, when running the same build on the May 2024 tag, this does not happen. The VM immediately drops to the shell and, although the NIC driver is loaded, none of the network stack is loaded.

The particulars:

• Building OVMF: build --platform OvmfPkg/OvmfPkgX64.dsc --tagname GCC --buildtarget DEBUG --arch X64
• Starting QEMU: qemu-system-x86_64 -machine q35,accel=kvm -m 2G -smp cpus=2 -cpu Nehalem-v2 -pflash /path/to/OVMF.fd
• Build from source of QEMU for version 10.0.50 (no mods to the source, just a build for something newer)

Those 2 commands work as expected using tag edk2-stable202402 but not with edk2-stable202405 (or after). Using the uefitool I can see that the DXE drivers are in OVMF.fd. What am I missing for this to work?

[YangGangUEFI]

Hi @AndrewFalanga, I think your issue is related to 4c4ceb2, which fixes a CVE vulnerability and introduces gEfiRngProtocolGuid to the network stack.

The boot logs can be helpful; you can check for messages like Driver A2F436EA-A127-4EF8-957C-8048606FF670 was discovered but not loaded!!.

You can try adding -device virtio-rng-pci to the QEMU parameters and booting again to see the results.

[AndrewFalanga]

Thank you @YangGangUEFI. Someone on Stackoverflow helped me to resolve this and he mentioned the same thing. I appreciate the link to the commit though. This helps to answer the when part of the question for the tags I mentioned in my original post. For anyone finding this exchange from a search, the inclusion of -device virtio-rng-pci does, indeed, correct the issue. It looks like, form the SHA posted here, that one might also adjust a PCD value but I've not experimented with that.