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.