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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Sep 06, 2016 at 04:21:25PM +0200, Paolo Bonzini wrote:
> 
> 
> 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.

I think we can expose the plug an play OS flag to guest,
upon seeing it, seabios can limit self to only
enumerating boot devices. No boot devices ->
skip pci init completely.


> >> 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