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

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

On Tue, Sep 06, 2016 at 06:48:57PM +0800, Chao Peng wrote:
> 
> > Patches 1-4 are okay, though I think it would be easier to add a -M
> > q35-lite too that just removes the legacy devices.  The -M q35-lite
> > machine doesn't have to support versioning for now.
> 
> Okay, this is also good to have in my mind.
> 
> > 
> > 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.

AFAIK latest seabios already supports DMA.
It's easy to add more config options for seabios
if you are so inclined.

> > 
> > 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
> (Also skipped firmware but some changes in patch 11 would move from
> QEMU to guest kernel). This way we also gain benefit of doing mmap
> kernel as you talked below. Not sure if this is something you can
> accpet.

I'm not sure I understand the question here. Accept what?


> > 
> > 3) PAM optimizations: for -M q35-lite initialize the machine with RAM
> > from 0xc0000 to 1MB.
> > 
> > I know that you ultimately would like to mmap the kernel, but I would
> > like to have a better understanding of where the time is spent.
> > 
> > Thanks,
> > 
> > Paolo