[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: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [RFC PATCH v2 00/12] Guest startup time optimization |
Date: |
Tue, 6 Sep 2016 14:53:21 +0300 |
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