qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 0/3] QEMU changes to do PVH boot


From: Maran Wilson
Subject: Re: [Qemu-devel] [RFC 0/3] QEMU changes to do PVH boot
Date: Wed, 5 Dec 2018 22:18:25 -0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 12/5/2018 2:37 PM, Liam Merwick wrote:
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, QEMU should be able to boot directly into the
uncompressed Linux kernel binary with minimal firmware involvement.

There already exists an ABI to allow this for Xen PVH guests and the ABI
is supported by Linux and FreeBSD:

    https://xenbits.xen.org/docs/unstable/misc/pvh.html

Details on the Linux changes: https://lkml.org/lkml/2018/4/16/1002

In case anyone wants to grab the patches and give it a try, I've just posted an updated version of the Linux patches rebased to the latest mainline code:

https://lkml.org/lkml/2018/12/6/26

No functional changes from before, just some minor conflict resolution as part of the rebase.

Thanks,
-Maran

qboot patches: http://patchwork.ozlabs.org/project/qemu-devel/list/?series=80020

This patch series provides QEMU support to read the ELF header of an
uncompressed kernel binary and get the 32-bit PVH kernel entry point
from an ELF Note.  This is called when initialising the machine state
in pc_memory_init().  Later on in load_linux() if the kernel entry
address is present, the uncompressed kernel binary (ELF) is loaded
and qboot does futher initialisation of the guest (e820, etc.) and
jumps to the kernel entry address and boots the guest.


Usіng the method/scripts documented by the NEMU team at

    https://github.com/intel/nemu/wiki/Measuring-Boot-Latency
    https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg00200.html

below are some timings measured (vmlinux and bzImage from the same build)
Time to get to kernel start is almost halved (95ṁs -> 48ms)

QEMU + qboot + vmlinux (PVH + 4.20-rc4)
  qemu_init_end: 41.550521
  fw_start: 41.667139 (+0.116618)
  fw_do_boot: 47.448495 (+5.781356)
  linux_startup_64: 47.720785 (+0.27229)
  linux_start_kernel: 48.399541 (+0.678756)
  linux_start_user: 296.952056 (+248.552515)

QEMU + qboot + bzImage:
  qemu_init_end: 29.209276
  fw_start: 29.317342 (+0.108066)
  linux_start_boot: 36.679362 (+7.36202)
  linux_startup_64: 94.531349 (+57.851987)
  linux_start_kernel: 94.900913 (+0.369564)
  linux_start_user: 401.060971 (+306.160058)

QEMU + bzImage:
  qemu_init_end: 30.424430
  linux_startup_64: 893.770334 (+863.345904)
  linux_start_kernel: 894.17049 (+0.400156)
  linux_start_user: 1208.679768 (+314.509278)


Liam Merwick (3):
   pvh: Add x86/HVM direct boot ABI header file
   pc: Read PVH entry point from ELF note in kernel binary
   pvh: Boot uncompressed kernel using direct boot ABI

  hw/i386/pc.c                | 344 +++++++++++++++++++++++++++++++++++++++++++-
  include/elf.h               |  10 ++
  include/hw/xen/start_info.h | 146 +++++++++++++++++++
  3 files changed, 499 insertions(+), 1 deletion(-)
  create mode 100644 include/hw/xen/start_info.h





reply via email to

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