qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v2 00/12] Guest startup time optimization


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH v2 00/12] Guest startup time optimization
Date: Tue, 6 Sep 2016 16:21:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0


On 06/09/2016 12:48, Chao Peng wrote:
>> As you might expect, I don't agree with removing the
>> firmware.  There's
>> room for much more optimization before duplicating firmware code in
>> QEMU.  I'd rather see numbers for:
>>
>> 1) qboot optimizations: adopt the fw_cfg DMA interface instead of the
>> cbfs flash hack (so that -kernel works), drop PCI bridge
>> initialization, copy less than 64K of memory from ROM to 0xf0000;
> 
> I can do the evaluation on qboot. Also adding Amnon Ilan, to see if
> there is some thing we can do for SeaBios.

For SeaBIOS we can try dropping PAM and PCI, but not much more.

I've pushed fw_cfg DMA support and some PAM  optimizations to qboot (it
doesn't setup PAM if QEMU doesn't configure 0xf0000-0x100000 as ROM).
I've left it for you to figure out which parts of PCI initialization can
be removed.

>> 2) Linux optimizations: using an uncompressed image to avoid the
>> cost of copying and decompressing.  QEMU can already load the image
>> at the right place and the real mode stub can do little more than
>> GDT/IDT setup.
> 
> This works surely. I actually followed your suggestion in v1 to make
> kernel multiboot-compatible and then load that kernel in QEMU directly

Please try posting the multiboot patches to the upstream x86 Linux
mailing list.  I am very interested in them, because I think it's the
simplest way to compare qboot with direct kernel load.  And as you say,
it might make patch 11 a little smaller and possibly more acceptable.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]