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

[Avi Kivity]

 On 08/03/2010 10:47 PM, Anthony Liguori wrote:
> On 08/03/2010 02:41 PM, Avi Kivity wrote:
> >  On 08/03/2010 10:38 PM, Anthony Liguori wrote:
> > > > Why do we need to transfer roms?  These are devices on the memory 
> > > > bus or pci bus, it just needs to be there at the right address.
> > >
> > >
> > > Not quite.  The BIOS owns the option ROM space.  The way it works on 
> > > bare metal is that the PCI ROM BAR gets mapped to some location in 
> > > physical memory by the BIOS, the BIOS executes the initialization 
> > > vector, and after initialization, the ROM will reorganize itself 
> > > into something smaller.  It's nice and clean.
> > >
> > > But ISA is not nearly as clean. 
> >
> > So far so good.
> >
> > > Ultimately, to make this mix work in a reasonable way, we have to 
> > > provide a side channel interface to SeaBIOS such that we can deliver 
> > > ROMs outside of PCI and still let SeaBIOS decide how ROMs get 
> > > organized.
> >
> > I don't follow.  Why do we need this side channel?  What would a real 
> > ISA machine do?
>
> It depends on the ISA machine.  In the worst case, there's a DIP 
> switch on the card and if you've got a conflict between two cards, you 
> start flipping DIP switches.  It's pure awesomeness.  No, I don't want 
> to emulate DIP switches :-)

How else do you set the IRQ line and I/O port base address?

 static ISADeviceInfo ne2000_isa_info = {
     .qdev.name  = "ne2k_isa",
     .qdev.size  = sizeof(ISANE2000State),
     .init       = isa_ne2000_initfn,
     .qdev.props = (Property[]) {
         DEFINE_PROP_HEX32("iobase", ISANE2000State, iobase, 0x300),
         DEFINE_PROP_UINT32("irq",   ISANE2000State, isairq, 9),
+      DEFINE_PROP_HEX32("rombase", ISANE2000State, isarombase, 0xe8000),
         DEFINE_NIC_PROPERTIES(ISANE2000State, ne2000.c),
         DEFINE_PROP_END_OF_LIST(),
     },
 };


we already are emulating DIP switches...

> >   Are there actually enough ISA devices for there to be a problem?
>
> No, but -M older has the same problem.

So we do the same solution we did in older.  We didn't have fwcfg dma 
back then.

> > > It's additionally complicated by the fact that we didn't support PCI 
> > > ROM BAR until recently so to maintain compatibility with -M older, 
> > > we have to use a side channel to lay out option roms.
> >
> > Again I don't follow.  We can just lay out the ROMs in memory like we 
> > did in the past?
>
> Because only one component can own the option ROM space.  Either 
> that's SeaBIOS and we need a side channel or it's QEMU and we can't 
> use PMM.
>
> I guess that's the real issue here.  Previously we used etherboot 
> which was well under 32k.  We only loaded roms we needed.  Now we use 
> gPXE which is much bigger and if you don't use PMM, then you run out 
> of option rom space very quickly.

A true -M older would use the older ROMs for full compatibility.

> Previously, we loaded option ROMs on demand when a user used -boot n 
> but that was a giant hack and wasn't like bare metal at all.  It 
> involved x86-isms in vl.c.  Now we always load ROMs so PMM is very 
> important.

Though it's a hack, we can load ROMs via the existing fwcfg interface; 
no need for an extension.  Richard is seeing problems loading 100MB 
initrds, not 64KB ROMs.

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