[Top][All Lists]

[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: Avi Kivity
Subject: Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?
Date: Wed, 04 Aug 2010 11:17:28 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1

 On 08/04/2010 10:56 AM, Gerd Hoffmann wrote:

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

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

For playing games, there are three options:
- existing fwcfg
- fwcfg+dma
- put roms in 4GB-2MB (or whatever we decide the flash size is) and have the BIOS copy them

Existing fwcfg is the least amount of work and probably satisfactory for isapc. fwcfg+dma is IMO going off a tangent. High memory flash is the most hardware-like solution, pretty easy from a qemu point of view but requires more work.

I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

reply via email to

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