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.. Ciao Claudio
