Hi, > > Can we get rid of the kernel command line hacking please? > > The virtio-mmio devices should be discoverable somehow. > > > > Device tree (as suggested by paolo) would work. > > Custom acpi device (simliar to fw_cfg) is another option. > > I'd tend to pick acpi, I wouldn't be surprised if we'll > > need acpi anyway at some point. > > > > Maybe even do both, then switch at runtime depending on -no-acpi > > (simliar to arm/aarch64). > > Microvm tries to do things in the cheapest possible way.
But taking too many shortcuts tends to hurt in the long run. It also cuts off useful use cases. I think microvm has more value than just the reduced boot time. Specifically the reduced attack surface is useful I think, even beyond container-style workloads. Being able to boot standard cloud images (with the cloud image kernel loaded via cloud image boot loader) in microvm would be useful for example. So, yes, I want microvm being designed in a way that it can run firmware and have it handle the boot process. For starters just qboot for fast direct kernel boot, but longer term also seabios and/or ovmf. Can look at the seabios side, but probably not before I'm back from my summer vacation in august. For seabios a simple & reliable time source would be quite useful. Direct kernel boot might be doable without that, but as soon as any I/O (read from cloud image disk) is involved a time source is needed. Right now seabios uses the acpi pm_timer. tsc should work too if seabios can figure the frequency without a calibration loop (invtsc should be enough). Maybe seabios needs kvmclock support ... Is there any way to detect microvm from the guest? pc/q35 can be easily detected by looking at the pci host bridge. Do you have boot time numbers for qboot vs. no-firmware boot? Is the difference big enough that it makes sense to maintain both? cheers, Gerd
