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

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

 



 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.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux