qemu-devel
[Top][All Lists]
Advanced

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

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 4/4] hw/i386: Introduce the microvm machine type
Date: Fri, 28 Jun 2019 23:56:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

On 28/06/19 23:05, Sergio Lopez wrote:
> The main reason for relying on Linux's Zero Page, is to be able to
> pass the e820 table with the basic physical memory layout to the kernel
> through it, as there isn't a BIOS nor ACPI. AFAIK, we can't do that with
> PVH.

e820 is passed through both PVH and multiboot.  qboot supports all
three, and also literally three 16-bit BIOS services for use with
vmlinuz.  I agree with Maran that it would be better to use a normal
firmware and reuse the fw_cfg code from the pc and q35 machine types.

qboot doesn't do mptable yet (it can only take ACPI tables from fwcfg)
but it should be easy to lift the SeaBIOS code that generate the tables.

It should be very interesting to have a comparison between running
"firmware" code in the host vs. the guest.

Another promising thing to do is to mmap the -kernel ELF file instead of
reading it.  You still have the memcpy when it is read into guest memory
with fw_cfg, but given Linux patches the heck out of itself at boot, it
should be faster to memcpy than to mmap vmlinux directly as MAP_PRIVATE
and hen suffer a thousand CoW page faults.

Thanks,

Paolo

> I'm inclined to keep it this way, and once there's an interest to use
> the microvm machine type with a different kernel, try to find some
> common ground.



reply via email to

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