On 18/07/19 16:34, Sergio Lopez wrote: > I've just added support for starting the machine from SeaBIOS (Stefan > Hajnoczi pointed in another thread that it can be as fast as qboot, and > given that the latter doesn't support mptables, I just tested this > one). I tried to keep it as minimalistic as possible, but it still > required an RTC (mc146818), which dragged in an ISA BUS, and this one a > KVM PIT. > > I ran some numbers using Stefano Garzarella's qemu-boot-time scripts > [1] on a server with 2xIntel Xeon Silver 4114 2.20GHz, using the > upstream QEMU (474f3938d79ab36b9231c9ad3b5a9314c2aeacde) built with > minimal features [2]. The VM boots a minimal kernel [3] without initrd, > using a kata container image as root via virtio-blk (though this isn't > really relevant, as we're just taking measurements until the kernel is > about to exec init). > > --------------------- > | QEMU with SeaBIOS | > --------------------- > > qemu_init_end: 65.958714 > linux_start_kernel: 77.735803 (+11.777089) > linux_start_user: 127.360739 (+49.624936) > > ------------------- > | QEMU direct PVH | > ------------------- > > qemu_init_end: 64.043264 > linux_start_kernel: 65.481782 (+1.438518) > linux_start_user: 114.938353 (+49.456571) > > -------------- > | Comparison | > -------------- > > Average boot time: > > * Relying on SeaBIOS, when compared with direct PVH boot, as a total > average overhead of ~12ms. The cost of initializing QEMU increases in > ~2ms (probably due to need to instantiate more devices), while the > other ~10ms is the SeaBIOS overhead. > > --------------- > | Conclusions | > --------------- > > Objectively, the version that boots directly the kernel using PVH is 10% > faster and has a slightly larger exposed surface. Whether this is enough > to justify its existence is quite subjective. > > In my opinion, not only I think it makes sense to have it, but I also > think there's little reason to have the firmware reliant version, given > the nature and purpose of microvm.
The advantage of firmware is support for vmlinuz and multiboot in addition to PVH, and removing code from QEMU. So I think it's still worth doing a comparison with qboot, and trying to understand where SeaBIOS is spending its time (qboot should not need additional devices other than fw_cfg, and since SeaBIOS has never been optimized for microvm I expect it's possible to shave quite a few of those 12 ms). On the other hand I agree that microvm is showing great promise compared to PCI-based machine types. Paolo
signature.asc
Description: OpenPGP digital signature