qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] qemu:cpuid: speedup test by 3x times if grub2 i


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH] qemu:cpuid: speedup test by 3x times if grub2 is available
Date: Mon, 18 Feb 2013 15:46:52 +0100

On Thu, 14 Feb 2013 11:51:59 -0200
Eduardo Habkost <address@hidden> wrote:

> On Thu, Feb 14, 2013 at 02:31:38PM +0100, Paolo Bonzini wrote:
> > Il 14/02/2013 14:24, Eduardo Habkost ha scritto:
> > > On Thu, Feb 14, 2013 at 01:13:18PM +0100, Paolo Bonzini wrote:
> > >> Il 14/02/2013 12:18, Eduardo Habkost ha scritto:
> > >>>>> qemu boots from disk image 3 times faster than direct kernel load.
> > >>> That's surprising. Do you have any idea why that happens?
> > >>
> > >> Because kernel load uses MMIO (from fw_cfg), while booting from disk
> > >> uses at worst PCI DMA and at best virtio.
> > > 
> > > Is it something worth trying to optimize
> > 
> > I think that, within the limits of what the spec makes legal, Gleb
> > optimized all that he could out of it.  The alternative is to make
> > fw_cfg do DMA, which in the past was rejected because it doesn't look
> > like what real ISA hardware would do.
> > 
> > > , or a reasonable solution would
> > > be so similar to having a disk+bootloader that's easier to simply
> > > recommend people to set up a real disk with a real bootloader if they
> > > care about speed?
> > 
> > In the end it's a pity, but yeah that's the easiest thing to do with
> > distro kernels and big all-drivers initrd.  -kernel is still useful and
> > fast enough if you have a custom-built kernel, possibly with no initrd
> > at all.
> 
> The patch that originated this thread wasn't even for distro kernels and
> big initrds. Our test case lods a very small test kernel (11 KB), and it
> is taking almost 15 seconds to boot.
> 
> Maybe our test case should create a custom BIOS image to be loaded on
> ROM, instead?

Problem was that gcc generated 2 LOAD sections with a hole ~128Mb between
them. And current implementation of ELF multiboot loader in QEMU just
allocates flat buffer of size=highest-lowest loaded address from ELF which
includes possible holes.

Possible fix is to exclude holes and pass a packed buffer to seabios, which
would require fixing multiboot rom as well (not sure if it could be made
compatible with migration to old qemu/seabios).



this hole.




reply via email to

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