From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhHMC-00060r-Qu for qemu-devel@nongnu.org; Tue, 06 Sep 2016 10:28:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhHM7-0006G2-1Y for qemu-devel@nongnu.org; Tue, 06 Sep 2016 10:28:11 -0400 Received: from mga01.intel.com ([192.55.52.88]:30961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhHM6-0006Ft-RZ for qemu-devel@nongnu.org; Tue, 06 Sep 2016 10:28:06 -0400 Message-ID: <1473172081.4674.23.camel@linux.intel.com> From: Chao Peng Date: Tue, 06 Sep 2016 22:28:01 +0800 In-Reply-To: <20160906144736-mutt-send-email-mst@kernel.org> References: <1472120105-29235-1-git-send-email-chao.p.peng@linux.intel.com> <1473158937.4143.15.camel@linux.intel.com> <20160906144736-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: "Michael S. Tsirkin" Cc: Haozhong Zhang , Xiao Guangrong , Eduardo Habkost , qemu-devel@nongnu.org, gor Mammedov , Paolo Bonzini , Amnon Ilan , Richard Henderson > > > 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; > > > > I can do the evaluation on qboot. Also adding Amnon Ilan, to see if > > there is some thing we can do for SeaBios. > > AFAIK latest seabios already supports DMA. > It's easy to add more config options for seabios > if you are so inclined. Yes, I tried that, the fw_cfg overhead in SeaBios/linuxboot optrom is already not a big issue for us. However, there are still some other code in SeaBIOS needs to be investigated. > > > > > > > > > > > > 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. > > > > This works surely. I actually followed your suggestion in v1 to > > make > > kernel multiboot-compatible and then load that kernel in QEMU > > directly > > (Also skipped firmware but some changes in patch 11 would move from > > QEMU to guest kernel). This way we also gain benefit of doing mmap > > kernel as you talked below. Not sure if this is something you can > > accpet. > > I'm not sure I understand the question here. Accept what? > I mean loading a multiboot kernel without the need for firmaware. Thanks, Chao