When assign PCI device, current code just map its bridge and its secondary bus number and devfn 0. It doesn''t work for PCI-x device assignment, because the request may be the source-id in the original PCI-X transaction or the source-id provided by the bridge. It needs to map the device itself, and its upstream bridges till PCIe-to-PCI/PCI-x bridge. In addition, add description for DEV_TYPE_PCIe_BRIDGE and DEV_TYPE_PCI_BRIDGE for understandability. Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Espen Skoglund
2008-Dec-19 12:55 UTC
Re: [Xen-devel][PATCH] VT-d: Fix PCI-X device assignment
Hmm... so the bridge does not take ownership of the request coming from PCI-X devices? As far as I remember, this was not my experience when I tried mapping a PCI-X device (or does my memory serve me wrong?) I guess different chipsets behaves differently then. Do you know if there is a way to detect how the bridge behaves? If the bridge does not take ownership of the requests then we don''t want to also map devfn 0 of the bus. eSk [Weidong Han]> When assign PCI device, current code just map its bridge and its > secondary bus number and devfn 0. It doesn''t work for PCI-x device > assignment, because the request may be the source-id in the original > PCI-X transaction or the source-id provided by the bridge. It needs > to map the device itself, and its upstream bridges till > PCIe-to-PCI/PCI-x bridge. In addition, add description for > DEV_TYPE_PCIe_BRIDGE and DEV_TYPE_PCI_BRIDGE for understandability.> Signed-off-by: Weidong Han <weidong.han@intel.com> > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Han, Weidong
2008-Dec-19 13:18 UTC
RE: [Xen-devel][PATCH] VT-d: Fix PCI-X device assignment
For PCI-X device, the requester-id "may" come from PCI-X device or its bridge. software must consider the possibility of requests arriving with the source-id in the original PCI-X transaction or the source-id provided by the bridge. You can refer to the 3.6.1.1 Devices Behind PCI Express to PCI/PCI-X Bridges in VT-d specification. BTW, I met DMA page faults when I assigned PCI-X device without my patch. Regards, Weidong Espen Skoglund wrote:> Hmm... so the bridge does not take ownership of the request coming > from PCI-X devices? As far as I remember, this was not my experience > when I tried mapping a PCI-X device (or does my memory serve me > wrong?) I guess different chipsets behaves differently then. Do you > know if there is a way to detect how the bridge behaves? If the > bridge does not take ownership of the requests then we don''t want to > also map devfn 0 of the bus. > > eSk > > > [Weidong Han] >> When assign PCI device, current code just map its bridge and its >> secondary bus number and devfn 0. It doesn''t work for PCI-x device >> assignment, because the request may be the source-id in the original >> PCI-X transaction or the source-id provided by the bridge. It needs >> to map the device itself, and its upstream bridges till >> PCIe-to-PCI/PCI-x bridge. In addition, add description for >> DEV_TYPE_PCIe_BRIDGE and DEV_TYPE_PCI_BRIDGE for understandability. > >> Signed-off-by: Weidong Han <weidong.han@intel.com> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jiang, Yunhong
2008-Dec-19 16:54 UTC
RE: [Xen-devel][PATCH] VT-d: Fix PCI-X device assignment
Espen, I think you can also refer to PCIE to PCI/X bridge spec fore more information. In sec 2.3. Assignment of Requester ID and Tag by the Bridge, it gives some items when will bridge take the ownership. Thanks Yunhong Jiang xen-devel-bounces@lists.xensource.com <> wrote:> For PCI-X device, the requester-id "may" come from PCI-X > device or its bridge. software must consider the possibility > of requests arriving with the source-id in the original PCI-X > transaction or the source-id provided by the bridge. You can > refer to the 3.6.1.1 Devices Behind PCI Express to PCI/PCI-X > Bridges in VT-d specification. > > BTW, I met DMA page faults when I assigned PCI-X device without my patch. > > Regards, > Weidong > > > Espen Skoglund wrote: >> Hmm... so the bridge does not take ownership of the request coming >> from PCI-X devices? As far as I remember, this was not my experience >> when I tried mapping a PCI-X device (or does my memory serve me >> wrong?) I guess different chipsets behaves differently then. Do you >> know if there is a way to detect how the bridge behaves? If the >> bridge does not take ownership of the requests then we don''t want to also >> map devfn 0 of the bus. >> >> eSk >> >> >> [Weidong Han] >>> When assign PCI device, current code just map its bridge and its >>> secondary bus number and devfn 0. It doesn''t work for PCI-x device >>> assignment, because the request may be the source-id in the original >>> PCI-X transaction or the source-id provided by the bridge. It needs >>> to map the device itself, and its upstream bridges till >>> PCIe-to-PCI/PCI-x bridge. In addition, add description for >>> DEV_TYPE_PCIe_BRIDGE and DEV_TYPE_PCI_BRIDGE for understandability. >> >>> Signed-off-by: Weidong Han <weidong.han@intel.com> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel