[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Multiple PCI bus support
I've played around with this, it seems to me the cleanest approach is to add PCI-PCIe bridge(s) or PCIe root port(s) to qemu-dm. Both can be used to function as PCIe-PCIe bridges (the bridge BAR allocations not the endpoint ones). Examples: A PCI-PCI bridge like the 31154 (then add PCIe extensions). http://www.intel.com/design/bridge/datashts/278821.htm An example is the Intel 965 Express Chipset Family datasheet Chapter 6. (c.f. http://www.intel.com/design/chipsets/datashts/313053.htm ) In either case, if you treat interrupts from the secondary as if they were INTx messages and "barber pole" them according to the PCI 3.0/PCIe spec everything "just works". (modulo the need for "reordering" in the PCIe spec to avoid deadlocks). -----Original Message----- From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Guy Zana Sent: Thursday, October 11, 2007 3:19 AM To: Tian, Kevin; xen-devel@xxxxxxxxxxxxxxxxxxx Subject: RE: [Xen-devel] Multiple PCI bus support > -----Original Message----- > From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx] > Sent: Thursday, October 11, 2007 10:27 AM > To: Guy Zana; xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Xen-devel] Multiple PCI bus support > > >From: Guy Zana > >Sent: 2007å10æ10æ 17:30 > > > >Hi, > > > >I saw that Xen support aÂtranslation between device/intx to > GSI for a > >single PCI bus, I thought about adding multiple PCI bus support but > >disregard the bus information so the same device/intx on different > >busesÂwill be OR wired to the same GSI, sounds reasonable? > What other > >things do I need to support in Xen in order to add multiple > PCI buses, > >assuming that secondary busesÂholds onlyÂPCI/PCIe devices? > > > >Thanks, > >Guy. > > > > GSI wire is platform specific (Qemu as platform) and thus you > can choose any policy including what you're proposing to Xen side. Yes, I saw how Qemu's irq_num is translated to device/intx, it's fairly easy to include bus information in this translation. I think it is best to let Xen stay with a single bus in its I/O APIC wiring. > > However to support multiple PCI buses presented to HVM guest, > the major work is in the Qemu: > 1. Emulate a virtual PCI-to-PCI bridge > 2. Add _PRT information in ACPI table under bridge > node, which stays consistent to Xen's wire logic > > If you want PCIe device to be seen as PCIe to HVM guest, you > need to do more: > 3. Change above bridge to PCI-to-PCIe bridge (any > standard spec?) > (Then advanced PCIe feature like AER/ASPM can't > be utilized) > Thanks, I'll look into the PCIe specific features, A PCIe switch may look like a virtual PCI-to-PCI bridge (according to the spec), except that, a multi-port root complex will expose PCI-to-PCIe bridges through the configuration. I assume there is nothing special in PCIe bridges, no? > But, any reason that assigned devices can't stay with current > single bus model? :-) It's just a training task :-) Thanks, Guy. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |