VirtIO drivers for QEMU Q35 releases

[krystian-hebel]

Bounty: $200

The problem you're addressing (if any)

UEFI payload in release v0.2.0 for Q35 doesn't include VirtIO drivers. Because of that, bootable disks have to be mounted using different interfaces, which are generally slower in virtualized environment.

Describe the solution you'd like

(Conditionally?) add VirtIO drivers to DasharoPayloadPkg.

Where is the value to a user, and who might that user be?

Slightly better performance of I/O operations.

Describe alternatives you've considered

No response

Additional context

• VirtIO driver enabled in edk2 build for QEMU
  • or possibly for all builds, but it should be loaded under QEMU only
• VirtIO test suite might go into this directory and be guarded by flags such as this one to make sure it's executed on QEMU machines only

Definition of done

• VirtIO edk2 driver is loaded when running on QEMU
• VirtIO driver is not loaded when running on some hardware platform
• Attached logs of newly developed test, proving VirtIO driver is visible in firmware

[aronowski]

I'll take it.

[macpijan]

@aronowski Do you have any progress or specific problems here?

[aronowski]

@macpijan, I have a WIP version of coreboot+edk2, where the drivers are included and built as part of the coreboot build job here, although ensuring that it works as intended is where I got stuck. By the looks of things, it should be fairly easy to check by entering UEFI Shell, running the drivers command and checking if there are any mentions of the drivers (draft version, likely needs further polishing), although I'm likely missing something simple to make sure that I can actually enter the shell itself - I have no option to enter it either in the graphical QEMU session or by running the dasharo-compatibility UEFI Shell test case, i.e. this doesn't work for me:

$ sudo setenforce 0
$ git clone https://github.com/dasharo/open-source-firmware-validation.git -b develop --depth 1
$ cd open-source-firmware-validation/
$ python3 -m virtualenv venv && source venv/bin/activate && pip install -r ./requirements.txt
$ ./scripts/ci/qemu-run.sh graphic firmware &
$ robot -L TRACE -v config:qemu-selftests -v rte_ip:127.0.0.1 -d ./logs/$(date +%Y.%m.%d_%H.%M.%S)/self-tests -v snipeit:no dasharo-compatibility/uefi-shell.robot
==============================================================================
Uefi-Shell                                                                    
==============================================================================
USH001.001 UEFI Shell :: Check whether the UEFI Shell is available... | FAIL |
Option UEFI Shell not found in the list
------------------------------------------------------------------------------
Uefi-Shell                                                            | FAIL |
1 test, 0 passed, 1 failed
==============================================================================
Output:  /home/user/open-source-firmware-validation/logs/2025.05.29_03.55.58/self-tests/output.xml
Log:     /home/user/open-source-firmware-validation/logs/2025.05.29_03.55.58/self-tests/log.html
Report:  /home/user/open-source-firmware-validation/logs/2025.05.29_03.55.58/self-tests/report.html

and I can only enter the Setup screen. What step am I missing here?

[macpijan]

although I'm likely missing something simple to make sure that I can actually enter the shell itself

The UEFI shell has been removed from release images, see this issue.

There are ways of adding it back as external app, if necessary.

But I believe the idea of testing it was a bit different here:

Attached logs of newly developed test, proving VirtIO driver is visible in firmware

Can you please briefly describe the scenario you had problems with @philipanda ?

[philipanda]

Dasharo on QEMU does not support VirtIO hard drives, which can be connected and disconnected on the fly.
A HDD can be connected to the machine by adding -drive file=${HDD_PATH},if=ide" to the qemu-system-x86_64 call, but such drive cannot be connected while QEMU is already running. We need a VirtIO drive for that and connect it using, for example, the Qemu Monitor Protocol, but Dasharo does not support them right now.

I believe adding such parameters to the call should mount the .img file as a virtio scsi drive:

  -device virtio-scsi-pci,id=scsi \
  -drive if=none,id=myhdd,format=raw,file=./my-drive.img \
  -device scsi-hd,drive=myhdd,bus=scsi.0 \

If such drive is detected, for example by the boot manager, if the image is bootable, then that would prove that the drivers are working.

If developing a test for this functionality in OSFV is required, then the drive can not be mounted in this way though. QEMU has to be already running and the drive should be connected dynamically, for example using the Qemu Monitor Protocol, because OSFV is not designed to interfere in how QEMU is started, just to interact with it.

In that case it might be required to use the lib/QemuMonitor.py OSFV library. It has been refurbished not that long ago, because it wasn't exactly working as expected. The branch was not merged yet, because mounting the drives can not be tested in firmware, as the firmware does not support it.

The simplest, although maybe not the most time efficient way to test this feature, would be to run the dasharo-compatibility/esp-scanning.robot test suite on the qemu-lib-refactor branch. The test mounts an image containing multiple bootable partitions, which then will be visible in the boot manager, provided the virtio drivers are working. Once it is known to work, a separate test case can be developed.

If you'd rather test the drivers by looking for them in the UEFI Shell, then you can still use the QMP and the lib/QemuMonitor lib to attach a virtual bootable USB flash drive containing the UEFI shell.

[aronowski]

@philipanda, thanks! I got this WIP version working with the hinted test suite at https://github.com/aronowski/coreboot/actions/runs/15340122209/job/43164816639.

I'd give developing that separate test case a shot, but perhaps as a separate ticket, since the DoD appears to be satisfied... or not? I did it this way:

In the platform description file (DasharoPayloadPkg.dsc) the required libraries and components are built unconditionally, in DasharoPayloadPkg.fdf the inclusion is conditional, i.e. with !if $(QEMU_PLATFORM) == TRUE - I'll rewrite it in a more elegant way, although have some questions:

• is that the only condition that needs to be true, or should I add some other ones? Right now my coreboot's QEMU-related configs used for the builds use CONFIG_EDK2_CUSTOM_BUILD_PARAMS="-D QEMU_PLATFORM=TRUE" to satisfy it.
• for simplicity's sake, currently only the [Components.X64] section has the relevant drivers mentioned, [Components.IA32] does not. Is it necessary for the latter to have them too?
• from the perspective of integrating the work: since satisfying the ticket's DoD would mean accepting two pull requests depending on each other, how should I post the work for acceptance? Coreboot's QEMU configs have references like CONFIG_EDK2_REPOSITORY="https://github.com/aronowski/edk2.git" and CONFIG_EDK2_TAG_OR_REV="virtio-drivers", so should I first have edk2 work accepted (after the fixes I mentioned above), then change the references in my coreboot fork to Dasharo's, and file another pull request, or have them both filed simultaneously?

[philipanda]

In the platform description file (DasharoPayloadPkg.dsc) the required libraries and components are built unconditionally, in DasharoPayloadPkg.fdf the inclusion is conditional, i.e. with !if $(QEMU_PLATFORM) == TRUE - I'll rewrite it in a more elegant way,

You can see how a small qemu-related contitional change can be made here Dasharo/edk2@e8cd185#diff-4c9d32b9f7d7dfb40b295a05a40ad511e85a6d9e499e7901abc79d21f9b18833

is that the only condition that needs to be true, or should I add some other ones? Right now my coreboot's QEMU-related configs used for the builds use CONFIG_EDK2_CUSTOM_BUILD_PARAMS="-D QEMU_PLATFORM=TRUE" to satisfy it.

QEMU_PLATFORM should be enough, like in the commit linked above.
I don't think it is necessary to use the CONFIG_EDK2_CUSTOM_BUILD_PARAMS in coreboot configs, because of these changes: Dasharo/coreboot@472336d#diff-ccc93bcd57ef2d7e881b451a9dc945c85f0a25fe3ed0cb7f5c097ab0da74df57R293

for simplicity's sake, currently only the [Components.X64] section has the relevant drivers mentioned, [Components.IA32] does not. Is it necessary for the latter to have them too?

We only use the q35 QEMU mainboard, which is x86_64, so I think that it should be perfectly fine to leave the drivers in [Components.X64].

from the perspective of integrating the work: since satisfying the ticket's DoD would mean accepting two pull requests depending on each other, how should I post the work for acceptance? Coreboot's QEMU configs have references like CONFIG_EDK2_REPOSITORY="https://github.com/aronowski/edk2.git" and CONFIG_EDK2_TAG_OR_REV="virtio-drivers", so should I first have edk2 work accepted (after the fixes I mentioned above), then change the references in my coreboot fork to Dasharo's, and file another pull request, or have them both filed simultaneously?

The changes in EDK2 do not depend on the changes in coreboot. Two PRs are needed and the one to EDK2 should be merged first.

Could you create the Pull Requests? It would be easier to review the changes that way

I'd give developing that separate test case a shot, but perhaps as a separate ticket, since the DoD appears to be satisfied... or not?

The DoD says to attach the logs of newly developed test, proving VirtIO driver is visible in firmware. The new test is not required to test the changes in EDK2 & coreboot, because the esp-scanning.robot test does that incidentally. It's not up to me to decide if we can omit that point, so maybe @macpijan you could share your opinion on that?

[aronowski]

@philipanda, thanks! This is the first PR.

Although I have a feeling there might be 3 PRs needed in total, rather than 2 - as far as I can see, qemu-run.sh in OSFV still uses if=ide in the qemu-lib-refactor branch (as per 63846a8).