Re: [Qemu-devel] [PATCH v2 4/4] hw/i386: Introduce the microvm machine type

[Gerd Hoffmann]

  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