zlacker

You're saying this is true on a Windows host?

>>datafl+(OP)
Yes. The delay you’re complaining about happens because you are looking at general hypervisors which also come with virtualized hardware and need to mimic a bunch of stuff so that most software will work as usual.

For example: your VM starts up with the CPU in 16 bit mode because that’s just how things work in x86 and then it waits for the guest OS to set the CPU into 64 bit mode.

This is completely unnecessary if you just want to run x86-64 code in a virtualized environment and you control the guest kernel and can just assume things are in 64bit mode because it’s not the 70s or whatever

The guest OS would also need to probe few ports to get a bootable disk. If you control the kernel then you can just not do that and boot directly.

There’s a ton of stuff that isn’t needed

>>akdev1+lq
The 16 bit mode stuff and the guest OS probes are after what I'm asking, not before.

>>datafl+Eq
No it is not. The “first instruction in the BIOS” is 16 bit mode code when dealing with an x86 VM.

A virtual environment doesn’t even really need any BIOS or anything like that.

You can feel free to test with qemu direct kernel booting to see this skips a lot of delay without even having to use a specialized hypervisor like firecracker

>>datafl+Eq
A bare VM may not have a BIOS, it's just partitioning supported by the host CPU and OS. The emulation of the legacy PC hardware stack for conventional OS compatibility is a separate thing. If the guest OS is custom-designed to launch in a bare VM with known topology it can boot very, very fast.