OSDev.org

Hi colleagues,

Here is just a quick question:
I am using qemu with OVMF and i notice that reading sectors with EFI_BLOCK_IO_PROTOCOL is quite slow.
Like really really noticeable slow.

Is this normal?

The OVMF code image i use, is the one installed by default.

Here is the cmdline of qemu (i don't think it is any relevant but still): Any thoughts?

Best regards,
CodePoet2005

It seems that you are not using hardware acceleration. QEMU is without it significantly slower in every case. I would also check which interface is used for your drive. If it is old PATA, that is also bottleneck. In emulators you will get fastest results if your drive is connected through VirtIO.

Hi,

VSlezak wrote: ↑Fri Mar 27, 2026 7:43 am It seems that you are not using hardware acceleration.

I just tested with accel enabled, but reading blocks is still noticeable slow (it is a bit faster though).

I am gonna check if i can change some qemu options and see if it makes any difference.
Unfortunately i don't think virtio is an option for me.

Also i just noticed that if i increase the ram, reading blocks with OVMF becomes slightly faster.

With accell and 4gb ram, it takes lets say around 0,2 sec to read a single block.
Still slow for large files but it is what it is.

Anyway thanks for the help.

Best regards,
CodePoet2005

Use the "-machine q35" parameter and you should see a considerable speed up.

- Ben
https://www.fysnet.net/osdesign_book_series.htm

BenLunt wrote: ↑Fri Mar 27, 2026 8:28 am Use the "-machine q35" parameter and you should see a considerable speed up.

Hi,

Thanks for the suggestion, indeed this option *significantly* increases speed (but why?).
I read on the internet that this option specifies a more recent chip set for the machine.
I guess this influences OVMF, reading sectors under qemu bios is quite fast.

Thanks for the help.

Best regards,
CodePoet2005

If I understand it correctly (I'm more of a Bochs guy than a QEMU guy), without specifying a recent chipset, the hardware is affected as well.

For example, without the recent chipset, your hard drives are ISA ATA drives using Port I/O, which is quite slow. With a recent chipset, the drives are now PCI(e) SATA drives using blocks of memory to transfer sectors, which is much faster.

If your project is far enough along to parse the PCI(e), exclude the "-machine -q35" parameter and you should not see any hard drives. Then include the parameter, and all the hard drives should show up as PCI(e) devices.

Again, if I understand it correctly, this parameter also affects the other hardware. For example, without, it uses the PIT, with, it uses HPET. Without, it uses the PIC, with, it uses the (x)APIC.

Again, I am a Bochs guy, so this is just my understanding of QEMU. I could be all wet here.

BenLunt wrote: ↑Fri Mar 27, 2026 9:12 amFor example, without the recent chipset, your hard drives are ISA ATA drives using Port I/O, which is quite slow. With a recent chipset, the drives are now PCI(e) SATA drives using blocks of memory to transfer sectors, which is much faster.

QEMU's default chipset includes a DMA-capable PCI IDE controller. I suspect the difference is that OVMF can fall back to PIO with the PCI IDE controller, whereas AHCI requires DMA for everything. (Perhaps I should try to confirm this with QEMU's trace log...)

BenLunt wrote: ↑Fri Mar 27, 2026 9:12 amIf your project is far enough along to parse the PCI(e), exclude the "-machine -q35" parameter and you should not see any hard drives.

Since QEMU's default PCI IDE controller is a PCI device, you will see it when you enumerate PCI.

BenLunt wrote: ↑Fri Mar 27, 2026 9:12 amAgain, if I understand it correctly, this parameter also affects the other hardware.

It does, but I don't think the other hardware would have a noticeable impact on OVMF performance. For example, I've only ever seen OVMF use the PIT, even when other timers are available.