From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGKoP-0003f2-KJ for qemu-devel@nongnu.org; Fri, 24 Jun 2016 02:41:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGKoM-0000a7-BB for qemu-devel@nongnu.org; Fri, 24 Jun 2016 02:41:57 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:2717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGKoM-0000a1-1k for qemu-devel@nongnu.org; Fri, 24 Jun 2016 02:41:54 -0400 References: <1466151257-96318-1-git-send-email-chao.p.peng@linux.intel.com> <20160620060129.GE21465@pengc-linux.bj.intel.com> <76b78e27-c14f-ebb5-baab-a0bf75a60a10@redhat.com> <20160623083238.GI21465@pengc-linux.bj.intel.com> <3ce886ab-d1f5-aff4-82bc-398f05f502a7@redhat.com> <576CD5B1.2010100@huawei.com> From: Claudio Fontana Message-ID: <576CD61C.9030802@huawei.com> Date: Fri, 24 Jun 2016 14:41:32 +0800 MIME-Version: 1.0 In-Reply-To: <576CD5B1.2010100@huawei.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/9] Introduce light weight PC platform pc-lite List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Chao Peng Cc: Haozhong Zhang , Xiao Guangrong , Eduardo Habkost , "Michael S. Tsirkin" , qemu-devel@nongnu.org, anthony.xu@intel.com, gor Mammedov , Richard Henderson On 24.06.2016 14:39, Claudio Fontana wrote: > Hi Paolo, > > On 23.06.2016 20:44, Paolo Bonzini wrote: >> >> >> On 23/06/2016 10:32, Chao Peng wrote: >>> The original usage model is to replace kvm-tool with QEMU for Clear >>> Containers (https://clearlinux.org/features/clear-containers). It's not >>> going to present the guest a real PC platform, but instead, a totally >>> virtual platform. >> >> It is not completely virtual; it has PCI for example. Hyper-V is an >> example of a completely virtual platform, even the LAPIC is customized >> with paravirtual features. >> >> qboot does basically four things: 1) relocate from ROM to 0xf0000; 2) >> initialize PCI; 2) provide the ACPI and e820 tables; 3) boot. >> >> If Linux can boot without initializing PCI bridges and without INTX, we >> can remove that code from qboot. The PCI scan is the most expensive >> part, I think. (2) and (3) are the same no matter if you run them in >> QEMU or the guest. >> >> That leaves out only relocation (PAM). >> >>> Every little bit boot time saving is important because >>> we are trying to achieve comparable result with that for Linux native >>> container. >>> >>> With this usage model, I doubt introducing a firmware layer is a good >>> idea: >>> >>> On one side, even with optimized and compact qboot it still takes us >>> ~15ms. >> >> Have you profiled it? If it is code in QEMU that we can optimize (e.g. >> memory.c), that would benefit all guests. >> >>> This is not a small value because current Linux kernel takes >>> only ~50ms (and we are still on the way to optimize it). And when >>> you look at the SeaBIOS or qboot, almost all the code are useless for >>> this usage model. They are doing things that is important for >>> traditional PC booting but cost 15ms doing useless things for us (It >>> is really not easy to save 15ms in other place, for example, in >>> Linux. Personally I tend to change the architecture for this new >>> usage model, e.g. eliminate firmware). >>> >>> On the other side, even boot the new pc-lite platform with firmware, >>> it does not mean it can support non-Linux system like Windows. So >>> generally I don't see the benefit of introducing a firmware layer. >> >> The main benefit is maintainability, by reducing the amount of code >> specific to pc-lite. >> >>> Besides, I'm also not quite sure if build around Q35 is the best >>> solution: >>> >>> The problem with Q35 is some features like SMM/SMRAM/PAM slow done >>> the booting even we actually never use them. While removing these >>> features can cause guest see different feature set for a same device >>> and it also prevents us to do further optimizations on that in guest. >> >> Of these, qboot only uses PAM, and even that could be removed (PAM is >> only necessary because of how qboot probes parallel flash). SMRAM >> should not slow down booting if you don't use them. Do they? >> >> Paolo > > I use qboot for similar goals, you mention that PAM is necessary because of how qboot probes parallel flash, > however in my custom platform I removed PAM completely from QEMU, and everything seems to work without any problems.. > Btw before you ask: yes I am booting with pflash. Ciao C.