Re: [Qemu-devel] [RFC PATCH v2 00/12] Guest startup time optimization

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Sep 02, 2016 at 01:08:29PM +0200, Paolo Bonzini wrote:
> 
> 
> On 25/08/2016 12:14, Chao Peng wrote:
> > This patchset is trying to optimize guest startup time by disabling
> > or simplifying some features in QEMU. The version 1 can be found at:
> > https://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg04842.html
> > 
> > Unlike version 1, this version optimizes Q35 directly instead of
> > introducing a totally new platform. But we still keep the design of
> > skipping firmware as till now we don't have good idea to optimize
> > firmware to get the comparable boot time.
> > 
> > The patchset is against commit 5f0e775 (Update version for v2.7.0-rc3
> > release) on master branch.
> > 
> > Basically this patchset introduces several switches to qemu comandline
> > so that several features can be turned off in some use cases. The
> > default behavior will not change in case no switches are provided.
> > 
> > Performance data:
> > feature(switches)       time saved in guest
> > -nosmbus                4ms
> > -nosata                 6ms
> > -nopic                  2ms
> > -nopit                  5ms
> > -static-prt             8ms
> > -nofw                   62ms
> > 
> > Thanks,
> > Chao
> > 
> > Chao Peng (9):
> >   pc: make smbus configurable
> >   pc: make sata configurable
> >   pc: make pic configurable
> >   pc: make pit configurable
> >   acpi: build static _PRT
> >   ich9: enable pm registers when there is no firmware
> >   q35: initialize MMCFG base when there is no firmware
> >   pc: support direct loading protected/long mode kernel
> >   pc: skip firmware
> > 
> > Haozhong Zhang (3):
> >   acpi: expose data structurs and functions of BIOS linker loader
> >   acpi: expose acpi_checksum()
> >   acpi: patch guest ACPI when there is no firmware
> > 
> >  hw/acpi/bios-linker-loader.c         |  83 +---------
> >  hw/acpi/core.c                       |   2 +-
> >  hw/acpi/nvdimm.c                     |   6 +-
> >  hw/i386/Makefile.objs                |   2 +-
> >  hw/i386/acpi-build-nofw.c            | 295 ++++++++++++++++++++++++++++++++++
> >  hw/i386/acpi-build.c                 | 102 +++++++-----
> >  hw/i386/acpi-build.h                 |   5 +
> >  hw/i386/pc.c                         | 301 +++++++++++++++++++++++++++++++----
> >  hw/i386/pc_piix.c                    |   2 +-
> >  hw/i386/pc_q35.c                     |  60 ++++---
> >  hw/isa/lpc_ich9.c                    |  12 +-
> >  hw/pci-host/q35.c                    |  15 +-
> >  include/hw/acpi/acpi.h               |   2 +
> >  include/hw/acpi/bios-linker-loader.h |  85 ++++++++++
> >  include/hw/i386/pc.h                 |  16 +-
> >  15 files changed, 800 insertions(+), 188 deletions(-)
> >  create mode 100644 hw/i386/acpi-build-nofw.c
> 
> Patches 1-4 are okay, though I think it would be easier to add a -M
> q35-lite too that just removes the legacy devices.  The -M q35-lite
> machine doesn't have to support versioning for now.

Where q35-lite will be same as q35 with different defaults?
Sure, I don't have a problem with this.
In particular this will allow things like "q35-lite but with sata" etc.

> As you might expect, I don't agree with removing the firmware.  There's
> room for much more optimization before duplicating firmware code in
> QEMU.  I'd rather see numbers for:
> 
> 1) qboot optimizations: adopt the fw_cfg DMA interface instead of the
> cbfs flash hack (so that -kernel works), drop PCI bridge initialization,
> copy less than 64K of memory from ROM to 0xf0000;
> 
> 2) Linux optimizations: using an uncompressed image to avoid the cost of
> copying and decompressing.  QEMU can already load the image at the right
> place and the real mode stub can do little more than GDT/IDT setup.
> 
> 3) PAM optimizations: for -M q35-lite initialize the machine with RAM
> from 0xc0000 to 1MB.
> 
> I know that you ultimately would like to mmap the kernel, but I would
> like to have a better understanding of where the time is spent.
> 
> Thanks,
> 
> Paolo