[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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@xxxxxxxxx> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@xxxxxxxxxxxxxxxxxxx >> http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |