[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.