On Apr 25, 2008, at 10:39 PM, Marcelo Tosatti wrote: > 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.
The Operating System can call _PIC to set IRQ routing on PIC mode (0) or APIC mode (1). Most DSDTs check for this and enable routing via "native" pins instead of going through the LNKx pseudo-devices. Unfortunately qemu was built around an ISA PC, so nearly everything is based on the assumption that we have two i8259 which can only handle 16 interrupts. This assumption even shows in parts where you wouldn't expect it (like piix_pci.c:228). At least I didn't ;-). I started messing with this today, to get interrupts working properly in Darwin. So maybe we can join efforts here to get the IRQ routing work as it should. In a perfect world (at least in mine) every PCI device would have a separate interrupt lane which is handled by an IRQ > 16. It might be worth considering MSI emulation for this too. Alex ------------------------------------------------------------------------- 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
