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

[Sergio Lopez]

Gerd Hoffmann <address@hidden> 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.

> 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.

Agreed.

> 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.

As I said, I'm also in favor of microvm supporting booting from
firmware in the future, as long we keep the simple mode too.

> 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.

> 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.

> 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.

Sergio.

signature.asc
Description: PGP signature