qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Sergio Lopez
Subject: Re: [Qemu-devel] [PATCH v2 4/4] hw/i386: Introduce the microvm machine type
Date: Tue, 02 Jul 2019 10:42:01 +0200
User-agent: mu4e 1.2.0; emacs 26.2

Gerd Hoffmann <address@hidden> writes:

>   Hi,
>
>> Microvm only supports booting PVH-enabled Linux ELF images. Booting
>> other PVH-enabled kernels may be possible, but due to the lack of ACPI
>> and firmware, we're relying on the command line for specifying the
>> location of the virtio-mmio transports. If there's an interest on
>> using this machine type with other kernels, we'll try to find some
>> kind of middle ground solution.
>
> 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. As I said the
other email, I'm not opposed to support qboot (which will probably imply
ACPI and/or device tree), as long it's optional, and the "cheap" way is
still present.

Otherwise, let's just drop microvm and stick with Q35 + qboot.

Sergio.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]