From: Sergio Lopez <slp@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: ehabkost@redhat.com, maran.wilson@oracle.com, mst@redhat.com,
Stefan Hajnoczi <stefanha@redhat.com>,
qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>,
Stefano Garzarella <sgarzare@redhat.com>,
rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v2 4/4] hw/i386: Introduce the microvm machine type
Date: Fri, 19 Jul 2019 12:30:43 +0200 [thread overview]
Message-ID: <875znypb8s.fsf@redhat.com> (raw)
In-Reply-To: <8cc45a56-1d12-838c-e746-e10df8804bc9@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4285 bytes --]
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 18/07/19 16:34, Sergio Lopez wrote:
>> I've just added support for starting the machine from SeaBIOS (Stefan
>> Hajnoczi pointed in another thread that it can be as fast as qboot, and
>> given that the latter doesn't support mptables, I just tested this
>> one). I tried to keep it as minimalistic as possible, but it still
>> required an RTC (mc146818), which dragged in an ISA BUS, and this one a
>> KVM PIT.
>>
>> I ran some numbers using Stefano Garzarella's qemu-boot-time scripts
>> [1] on a server with 2xIntel Xeon Silver 4114 2.20GHz, using the
>> upstream QEMU (474f3938d79ab36b9231c9ad3b5a9314c2aeacde) built with
>> minimal features [2]. The VM boots a minimal kernel [3] without initrd,
>> using a kata container image as root via virtio-blk (though this isn't
>> really relevant, as we're just taking measurements until the kernel is
>> about to exec init).
>>
>> ---------------------
>> | QEMU with SeaBIOS |
>> ---------------------
>>
>> qemu_init_end: 65.958714
>> linux_start_kernel: 77.735803 (+11.777089)
>> linux_start_user: 127.360739 (+49.624936)
>>
>> -------------------
>> | QEMU direct PVH |
>> -------------------
>>
>> qemu_init_end: 64.043264
>> linux_start_kernel: 65.481782 (+1.438518)
>> linux_start_user: 114.938353 (+49.456571)
>>
>> --------------
>> | Comparison |
>> --------------
>>
>> Average boot time:
>>
>> * Relying on SeaBIOS, when compared with direct PVH boot, as a total
>> average overhead of ~12ms. The cost of initializing QEMU increases in
>> ~2ms (probably due to need to instantiate more devices), while the
>> other ~10ms is the SeaBIOS overhead.
>>
>> ---------------
>> | Conclusions |
>> ---------------
>>
>> Objectively, the version that boots directly the kernel using PVH is 10%
>> faster and has a slightly larger exposed surface. Whether this is enough
>> to justify its existence is quite subjective.
>>
>> In my opinion, not only I think it makes sense to have it, but I also
>> think there's little reason to have the firmware reliant version, given
>> the nature and purpose of microvm.
>
> The advantage of firmware is support for vmlinuz and multiboot in
> addition to PVH, and removing code from QEMU. So I think it's still
> worth doing a comparison with qboot, and trying to understand where
> SeaBIOS is spending its time (qboot should not need additional devices
> other than fw_cfg, and since SeaBIOS has never been optimized for
> microvm I expect it's possible to shave quite a few of those 12 ms).
I tweaked qboot a bit to make it work with microvm (basically, if it
can't identify a PCI vendor, it assumes it's running in a microvm, and
avoids PCI and ACPI initialization, writing an minimal mptable instead)
and I've just got some numbers:
Average boot time:
qemu_init_end: 64.502199
linux_start_kernel: 66.644311 (+2.142112)
linux_start_user: 116.279127 (+49.634816)
To avoid having to scroll up, these are the numbers with the direct PVH
boot version:
Average boot time:
qemu_init_end: 64.043264
linux_start_kernel: 65.481782 (+1.438518)
linux_start_user: 114.938353 (+49.456571)
So starting from qboot is just a bit over 1ms slower, which I think it's
quite reasonable. And, as you said, the only additional device is
fw_cfg:
address-space: I/O
0000000000000000-000000000000ffff (prio 0, i/o): io
000000000000007e-000000000000007f (prio 0, i/o): kvmvapic
0000000000000510-0000000000000511 (prio 0, i/o): fwcfg
0000000000000514-000000000000051b (prio 0, i/o): fwcfg.dma
If people feel more comfortable keeping QEMU on x86_64 starting on Real
Mode and having the firmware writing mptables, I'm fine with taking this
approach.
That said, to avoid confusing users, I think it'd be better to drop the
legacy mode for SeaBIOS, and support just qboot. That would mean having
to add a binary from the latter to "pc-bios" with some descriptive name
("qboot-microvm.bin"?) and making microvm look for that one by default.
Does this sound like a reasonable plan?
> On the other hand I agree that microvm is showing great promise compared
> to PCI-based machine types.
>
> Paolo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-07-19 10:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-01 14:47 [Qemu-devel] [PATCH v2 0/4] Introduce the microvm machine type Sergio Lopez
2019-07-01 14:47 ` [Qemu-devel] [PATCH v2 1/4] hw/virtio: Factorize virtio-mmio headers Sergio Lopez
2019-07-01 14:47 ` [Qemu-devel] [PATCH v2 2/4] hw/i386: Add an Intel MPTable generator Sergio Lopez
2019-07-02 8:02 ` Gerd Hoffmann
2019-07-02 8:37 ` Sergio Lopez
2019-07-02 9:33 ` Gerd Hoffmann
2019-07-01 14:47 ` [Qemu-devel] [PATCH v2 3/4] hw/i386: Factorize PVH related functions Sergio Lopez
2019-07-01 14:47 ` [Qemu-devel] [PATCH v2 4/4] hw/i386: Introduce the microvm machine type Sergio Lopez
2019-07-02 8:17 ` Gerd Hoffmann
2019-07-02 8:42 ` Sergio Lopez
2019-07-02 10:16 ` Gerd Hoffmann
2019-07-02 10:52 ` Sergio Lopez
2019-07-02 11:50 ` Gerd Hoffmann
2019-07-02 14:06 ` Paolo Bonzini
2019-07-02 14:41 ` Sergio Lopez
2019-07-18 14:34 ` Sergio Lopez
2019-07-18 15:48 ` Paolo Bonzini
2019-07-19 10:30 ` Sergio Lopez [this message]
2019-07-19 11:49 ` Paolo Bonzini
2019-07-02 8:19 ` Stefano Garzarella
2019-07-02 8:47 ` Sergio Lopez
2019-07-02 10:37 ` Paolo Bonzini
2019-07-02 11:16 ` Sergio Lopez
2019-07-01 18:32 ` [Qemu-devel] [PATCH v2 0/4] " no-reply
2019-07-01 19:06 ` no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875znypb8s.fsf@redhat.com \
--to=slp@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kraxel@redhat.com \
--cc=maran.wilson@oracle.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).