On Fri, Apr 25, 2008 at 11:38:21AM +0200, Alexander Graf wrote: > > On Apr 25, 2008, at 3:01 AM, Marcelo Tosatti wrote: > > > > >Add three PCI bridges to support 128 slots. Vendor and device_id have > >been stolen from my test box. > > > >I/O port addresses behind each bridge are statically allocated > >starting > >from 0x2000 with 0x1000 length. Once the bridge runs out of I/O space > >the guest (Linux at least) happily allocates outside of the region. > >That > >needs verification. > > > >I/O memory addresses are divided between 0xf0000000 -> APIC base. > > > >The PCI irq mapping function is also changed, there was the assumption > >that devices behind the bridge use the IRQ allocated to the bridge > >device itself, which is weird. Apparently this is how the SPARC ABP > >PCI > >host works (only user of the bridge code at the moment). > > Is there any reason we're not using the _PIC function and give the OS > a clue on which APIC pin the device is? Right now everything boils > down to LNKA - LNKD which it does not have to. > It might even be a good idea to connect each PCI device to a specific > APIC pin, so we don't need to share too much, which might become a > problem with a lot of PCI devices. As far as I know there is no > limitation on how many pins an APIC may have.
I was not aware of the _PIC function. Will take a look at it. The number of IRQ's certainly needs to increase. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
