Re: [Qemu-devel] [RFC 0/9] Introduce light weight PC platform pc-lite

[Claudio Fontana <claudio.fontana@huawei.com>]

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