From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgjmX-0007HR-8I for qemu-devel@nongnu.org; Sun, 04 Sep 2016 22:37:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgjmS-0003ij-S5 for qemu-devel@nongnu.org; Sun, 04 Sep 2016 22:37:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgjmS-0003iY-KB for qemu-devel@nongnu.org; Sun, 04 Sep 2016 22:37:04 -0400 Date: Mon, 5 Sep 2016 05:37:00 +0300 From: "Michael S. Tsirkin" Message-ID: <20160905053519-mutt-send-email-mst@kernel.org> References: <1472120105-29235-1-git-send-email-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC PATCH v2 00/12] Guest startup time optimization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Chao Peng , qemu-devel@nongnu.org, gor Mammedov , Xiao Guangrong , Richard Henderson , Eduardo Habkost , Haozhong Zhang 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