From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: QEMU/KVM [RFC]: add support for 128 PCI slots Date: Fri, 25 Apr 2008 17:39:16 -0300 Message-ID: <20080425203916.GA9617@dmt> References: <20080425010114.GA16676@dmt> <3DA29361-81E2-486A-B32B-66A9E280C135@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Chris Wright , kvm-devel , Avi Kivity To: Alexander Graf Return-path: Content-Disposition: inline In-Reply-To: <3DA29361-81E2-486A-B32B-66A9E280C135@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org 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