qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
Date: Wed, 04 Aug 2010 11:22:08 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100628 Red Hat/3.1-1.el6 Thunderbird/3.1

On 08/04/10 10:17, Avi Kivity wrote:
On 08/04/2010 10:56 AM, Gerd Hoffmann wrote:
Hi,

(1) -M somethingold. PCI devices don't have a pci rom bar then by
default because they didn't not have one in older qemu versions,
so we need some other way to pass the option rom to seabios.

What did we do back then? before we had the fwcfg interface?

Have qemu instead of bochs/seabios manage the vgabios/optionrom area
(0xc8000 -> 0xe0000) and copy the roms to memory. Which implies the
whole rom has to sit there as PMM can't be used then.

Do we actually need PMM for isapc? Did PMM exist before pci?

I don't know.

(3) roms not associated with a PCI device: multiboot, extboot,
-option-rom command line switch, vgabios for -M isapc.

We could lay those out in high memory (4GB-512MB) and have the bios copy
them from there.

Yea, we could. But it is pointless IMHO.

$ ls -l *.bin
-rwxrwxr-x. 1 kraxel kraxel 1536 Jul 15 15:51 extboot.bin*
-rwxrwxr-x. 1 kraxel kraxel 1024 Jul 15 15:51 linuxboot.bin*
-rwxrwxr-x. 1 kraxel kraxel 1024 Jul 15 15:51 multiboot.bin*
-rwxrwxr-x. 1 kraxel kraxel 8960 Jul 15 15:51 vapic.bin*

That are the ones we can't load via pci rom bar. Look how small they are.

So they can just sit there? I'm confused, either there is enough address
space and we don't need to play games, or there isn't and we do.

Well.  Looks like I should be a bit more verbose.

The old (qemu 0.11) way was to have qemu load roms to memory and bochsbios/seabios scan the memory area for option rom signatures to find them. All option roms have to fit in there then, completely:

  vgabios        (~40k)
  etherboot rom  (~32k)
  extboot rom    (~1k)

The new way is to have seabios load roms to memory:

  vgabios         (~40k)
  gPXE rom header (~2k IIRC)
  extboot rom     (~1k)

Thanks to SeaBIOS loading the roms only a small part of the gPXE rom has to live in the option rom area, everything else is stored somewhere else in high memory (using PMM, don't ask me how this works in detail). gPXE roms are ~56k in size (e1000 even 72k), so they would fill up the option rom area pretty quickly if we would load them the old way without PMM.

Another advantage of seabios loading the roms is that parts of the 0xe0000 segment can be used then. Seabios size is just a bit more than 64k, so most of the 0xe0000 -> 0xf0000 area isn't actually used by seabios.

seabios has two ways get the roms: (1) fw_cfg and (2) pci rom bar. The ones listed above are the ones which have to go through fw_cfg. There are more roms which have to fit into the option rom space (vgabios, one gPXE per nic), but these don't depend on fw_cfg.

For playing games, there are three options:
- existing fwcfg

Gived the size that is good+fast enougth for the roms IMO.

Kernel+initrd is another story though. We are talking about megabytes not kilobytes then. Standard fedora initramfs is ~14M on x86_64.

cheers,
  Gerd




reply via email to

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