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

[Gleb Natapov]

On Wed, Aug 04, 2010 at 09:22:22AM -0500, Anthony Liguori wrote:
> On 08/04/2010 08:26 AM, Gleb Natapov wrote:
> >On Wed, Aug 04, 2010 at 02:24:08PM +0100, Richard W.M. Jones wrote:
> >>On Wed, Aug 04, 2010 at 08:15:04AM -0500, Anthony Liguori wrote:
> >>>On 08/04/2010 08:07 AM, Gleb Natapov wrote:
> >>>>On Wed, Aug 04, 2010 at 08:04:09AM -0500, Anthony Liguori wrote:
> >>>>>On 08/04/2010 03:17 AM, Avi Kivity wrote:
> >>>>>>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.
> >>>>>
> >>>>>The only trouble I see is that high memory isn't always available.
> >>>>>If it's a 32-bit PC and you've exhausted RAM space, then you're only
> >>>>>left with the PCI hole and it's not clear to me if you can really
> >>>>>pull out 100mb of space there as an option ROM without breaking
> >>>>>something.
> >>>>>
> >>>>We can map it on demand. Guest tells qemu to map rom "A" to address X by
> >>>>writing into some io port. Guest copies rom. Guest tells qemu to unmap
> >>>>it. Better then DMA interface IMHO.
> >>>That's what I thought too, but in a 32-bit guest using ~3.5GB of
> >>>RAM, where can you safely get 100MB of memory to full map the ROM?
> >>>If you're going to map chunks at a time, you are basically doing
> >>>DMA.
> >>It's boot time, so you can just map it over some existing RAM surely?
> >Not with current qemu. This  is broken now.
> 
> But even if it wasn't it can potentially create havoc.  I think we
> currently believe that the northbridge likely never forwards RAM
> access to a device so this doesn't fit how hardware would work.
> 
Good point.

> More importantly, BIOSes and ROMs do very funny things with RAM.
> It's not unusual for a ROM to muck with the e820 map to allocate RAM
> for itself which means there's always the chance that we're going to
> walk over RAM being used for something else.
> 
ROM does not muck with the e820. It uses PMM to allocate memory and the
memory it gets is marked as reserved in e820 map.

--
                        Gleb.