Cannot get virtio-net drivers working - build script for example ISO included

[J-A-M-E-5]

I am trying to make a ISO to run under VirtualBox. If I include the Intel 82545EM drivers and virtio-net drivers, it only works and detects the adaptor when I specify the Intel one in VirtualBox config. If I change it to virtio-net it does not work - the adapter isn't even detected. I've tried EFI, BIOS 32-bit/64-bit. This example is BIOS 32-bit to keep things simple... as expected if I choose for example "PCnet-FAST III" as the VBox interface it does not work just the same as virtio doesn't, as I am not including driver for that in my ISO. However I'd expect virtio to work as I am building the driver!

ISO Build script:

#!/bin/bash

# Build test script for ISO

cat <<EOF >/tmp/isoboot.ipxe
#!ipxe
ifstat || echo ifstat error
dhcp || echo dhcp error
prompt
reboot
EOF

# Git sanity check (to show no mods to any file)

cd ~/ipxe
git status
echo Git revision: $(git rev-parse --short HEAD)

# Build ISO with just Intel 82545EM and virtio-net drivers

cd src
rm -f bin/82545em--virtio-net.iso
make bin/82545em--virtio-net.iso EMBED=/tmp/isoboot.ipxe
echo Size of ISO: $(stat -c%s bin/82545em--virtio-net.iso) bytes

Output from build script:-

On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
Git revision: c1834f32
  [DEPS] image/embedded.c
  [BUILD] bin/embedded.o
  [AR] bin/blib.a
  [VERSION] bin/version.82545em--virtio-net.lkrn.o
  [LD] bin/82545em--virtio-net.lkrn.tmp
  [BIN] bin/82545em--virtio-net.lkrn.bin
  [ZINFO] bin/82545em--virtio-net.lkrn.zinfo
  [ZBIN] bin/82545em--virtio-net.lkrn.zbin
  [FINISH] bin/82545em--virtio-net.lkrn
  [GENFSIMG] bin/82545em--virtio-net.iso
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.

rm bin/82545em--virtio-net.lkrn bin/version.82545em--virtio-net.lkrn.o bin/82545em--virtio-net.lkrn.zinfo bin/82545em--virtio-net.lkrn.zbin bin/82545em--virtio-net.lkrn.bin
Size of ISO: 612352 bytes

Screenshot of issue:-

Am I missing some sort of config or flag to get the virtio driver working? Thanks in advance.

P.S. Worth mentioning perhaps that official ISO downloaded from https://boot.ipxe.org/ipxe.iso doesn't work either - shows no results for ifstat command. Also if I do a make bin-i386-efi/ipxe.iso I get a working ISO if I switch to EFI, but it is using SNP and not the virtio drivers as I required. My end goal is not to actually create an ISO, I've just done this to simplify the problem I was experiencing with chainloading virtio which also doesn't work.

[NiKiZe]

Grab the pciid of the device that don't work to check if there is native drivers in iPXE, if they are using virtio devices then maybe they are using a different pciid from what has been added to iPXE

There is also a named config for vbox, but that is probably more useful when you are building a ROM.

In EFI mode you should also have SNP and NII which iPXE should be able to fallback on, but maybe they dont include any efi drivers for the NICs?

[J-A-M-E-5]

1af4:1000 is the PCI-ID. This is defined in drivers/net/virtio-net.c:

static struct pci_device_id virtnet_nics[] = {
PCI_ROM(0x1af4, 0x1000, "virtio-net", "Virtio Network Interface", 0),
PCI_ROM(0x1af4, 0x1041, "virtio-net", "Virtio Network Interface 1.0", 0),
};

I want to use virtio-net for maximum performance when transferring big files. I also want to attempt to flash the virtualbox ROM (yes I know about the 64KB limit and how it was breached, but I did get lower than it with similar result to this non-detection). It appears the underlying virtio-net driver/code doesn't work as I am attempting to prove by simplifying this to an ISO.

You're correct that "vbox" named config to build a .isarom could be useful. I understand it once was until the code updates (getting more bigger) made the rom file too big for virtualbox to handle. I'd be happy being able to chainload a version which utilises virtio-net driver, but I am unable to get it working anywhere, it either doesn't work or uses for example SNP.

[NiKiZe]

Good, then try adding DEBUG=virtio-net to your make line

[J-A-M-E-5]

Good, then try adding DEBUG=virtio-net to your make line

OK thanks, have done that. I see the following debug message when running ISO on i386/BIOS:-

VIRTIO-NET modern 0x20d5c busaddr=0000:00:03.0 irq=9

[J-A-M-E-5]

OK, I've tried something else. If you SVN the Virtualbox source you'll find this folder https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/ipxe which is an old version (would love to identify which exact git hash) of IPXE.

If you copy 2 files from the current version to fix some compile errors with latest gcc:-

src/arch/x86/include/bits/bigint.h
src/arch/x86/core/x86_bigint.c

And if you delete one driver folder which throws a load of errors:-

rm -Rf src/drivers/net/ath/

With the following it will create a i386 BIOS ISO:-

cd src && make bin/82545em--virtio-net.iso EMBED=/tmp/isoboot.ipxe DEBUG=intel,virtio-net

However I get the same results. Intel driver works, virtio-net doesn't:-

So it would appear virtio-net has never been designed to run from ISO, from chainload, from anything other than being custom built in someway by the VirtualBox ROM build process. The folder above src has a Makefile.kmk which appears to be some other buildchain I need to study. It's a shame cause I'd love to get virtio-net working from a ISO or chainload as I am sure performance will be better with large images. Chainload or ISO are needed cause not enough space to offer HTTP and other features within the 64K ROM limits.

[NiKiZe]

Virtio is working perfectly fine, in QEMU.
Usually you have a minimal iPXE in ROM which then chains a fuller iPXE version.
However the 64k limit should have been fixed already in vbox.

Try adding :3 to debug or keep digging further into why it fails to initialize.

[J-A-M-E-5]

Try adding :3 to debug or keep digging further into why it fails to initialize.

I added :3 to the debug and got no further info.

I've tried the ISO I made with QEMU (no KVM as I'm on MacOs host):-

With all 3 of these virtio-net variations it works in as far as the virtio-net is detected and link comes up:-

qemu-system-i386 -boot d -cdrom 82545em--virtio-net.iso -m 64 -nic user,model=virtio-net-pci
qemu-system-i386 -boot d -cdrom 82545em--virtio-net.iso -m 64 -nic user,model=virtio-net-pci-non-transitional
qemu-system-i386 -boot d -cdrom 82545em--virtio-net.iso -m 64 -nic user,model=virtio-net-pci-transitional 

So obviously there's an issue with VirtualBox. I'm at a loss, would be interested if anyone reading who runs VBox on Windows or Linux can successfully use the ISO as created in post #1 above? I'm running 7.0.10 on Monterey 12.6.8

VirtualBox ticket created for those interested: https://www.virtualbox.org/ticket/21813

[J-A-M-E-5]

OK @NiKiZe VirtualBox have told me the issue is with iPXE and have produced a patch for iPXE, and it works:-

diff --git a/src/drivers/bus/virtio-pci.c b/src/drivers/bus/virtio-pci.c
index 8b34c727..3fc93a90 100644
--- a/src/drivers/bus/virtio-pci.c
+++ b/src/drivers/bus/virtio-pci.c
@@ -230,10 +230,10 @@ u32 vpm_ioread32(struct virtio_pci_modern_device *vdev,
     uint32_t data;
     switch (region->flags & VIRTIO_PCI_REGION_TYPE_MASK) {
     case VIRTIO_PCI_REGION_MEMORY:
-        data = readw(region->base + offset);
+        data = readl(region->base + offset);
         break;
     case VIRTIO_PCI_REGION_PORT:
-        data = inw(region->base + offset);
+        data = inl(region->base + offset);
         break;
     case VIRTIO_PCI_REGION_PCI_CONFIG:
         prep_pci_cfg_cap(vdev, region, offset, 4);

All credit to aeichne:-

A bit of technical background. VirtIO states that register accesses must be aligned and sized to the natural register width. vpm_ioread32() is supposed to read a 32-bit register but the code apparently tries to read 16-bit only which makes our emulation ignore it. qemu might be a bit more relaxed in that regard but it is clearly a bug in ipxe causing the device to not transition to the modern 1.0 Virtio standard but remaining in legacy mode. This should probably be reported to the ipxe maintainers (might do it myself).

I've tested this patched version with qemu and no regressions or anything.

[NiKiZe]

A PR exists #1028 thanks for the confirmation that it works.