Re: [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

[Chao Gao <chao.gao@intel.com>]

On Wed, Jul 05, 2017 at 09:29:29AM +0100, Roger Pau Monné wrote:
>On Wed, Jul 05, 2017 at 02:19:17AM -0600, Jan Beulich wrote:
>> >>> On 05.07.17 at 09:56, <chao.gao@intel.com> wrote:
>> > How about changing the second paragraph to:
>> > 
>> > If a PF is an extended function, the BDF of a traditional function
>> > within the same device should be used to search VT-d unit. Otherwise,
>> > the real BDF of PF should be used. According PCI-e spec, an extended
>> > function is a function within an ARI device and Function Number > 7.
>> > But the original code only checks the latter requirement, without
>> > checking the former requirement. It incurs that a function whose Function
>> > Number > 7 but which isn't within an ARI device (such as RC integrated
>> > function with Function Number > 7) is wrongly classified to an extended
>> > function and then we wrongly use 0 as 'devfn' to search VT-d unit for this
>> > case.
>> 
>> There's one part here which I continue to not understand: The
>> function number being just 3 bits, how can it possibly be larger
>> than 7?
>
>It's a special case on the PCIe spec, quoting it:
>
>"Note: for Requests targeting Extended Functions in an ARI Device,
>A[19:12] represents the (8-bit) Function Number, which replaces the
>(5-bit) Device Number and (3-bit) Function Number fields above."
>
>It's in the PCIe 3.1a spec, page 657. The function number is expanded
>from 7 to 255.
>
>What I fail to see is how this device is registered with Xen, is the
>devfn field used to store the function number only?

The devfn is passed down by dom0. Judging from how is_extfn is set in
xen_add_device() in linux kernel, I think linux kernel reuses the Device
Fields as the higher 5 bits of an extended function's Function Number. 

Thanks
Chao

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel