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

[Avi Kivity <avi@redhat.com>]

  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.