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

[Gerd Hoffmann <kraxel@redhat.com>]

On Tue, Jul 02, 2019 at 12:52:27PM +0200, Sergio Lopez wrote:
> 
> Gerd Hoffmann <kraxel@redhat.com> writes:
> 
> >   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.
> 
> Sure, but the consideration about whether there are too many shortcuts,
> or just enough of them, is quite subjective. Microvm's code base is
> small enough to keep its quirks in check without a becoming a
> significant maintenance burden, and doesn't invalidate how other, more
> conventional machine types work.

Most projects starts small, but then tend to grow over time.
And likewise the maintenance burden tends to grow over time ...

> > 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 ...
> 
> My main concern about supporting SeaBIOS, in addition to boot times, is
> having to support ACPI, which due to its complexity and size, is a clear
> candidate to be stripped out from a minimalistic QEMU build.

Not sure dropping apci will be much of a win.  I think the aml generator
hasn't any external dependencies (increasing load time due to shared
libs).  The guest interface is rather small too (only reading tables via
fw_cfg).  I'd also expect microvm doesn't need many tables due to the
small feature set (no numa, no pci, ...).

On the other hand acpi tables plus some minimal apci registers would
provide some useful features.  apci poweroff,  acpi power button,  apci
pm-timer.  You also could describe the virtio-mmio devices.

Having said that I think it should be possible to change seabios that
it'll work without acpi too.  It would still need some way to discover
virtio-mmio devices though if we want it load guest kernels from disk
images.

> > Is there any way to detect microvm from the guest?  pc/q35 can be
> > easily detected by looking at the pci host bridge.
> 
> One option would be using the fields MPC_OEM and MPC_PRODUCT_ID from the
> MP Table to give a hint to the guest.

Well, I mean for the firmware.  When booting with firmware all those
tables (mptable, e820, ...) should be created by the firmware not qemu.

It's not that critical though.  We probably want a separate seabios
build for microvm anyway, so a compile time option should work too.

> > Do you have boot time numbers for qboot vs. no-firmware boot?
> > Is the difference big enough that it makes sense to maintain both?
> 
> AFAIK, qboot can't boot a guest without both ACPI and PCI.

Should be fixable I guess ...

cheers,
  Gerd