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

[Claudio Fontana]

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.