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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Jul 05, 2017 at 02:19:17AM -0600, Jan Beulich wrote:
> >>> On 05.07.17 at 09:56, <chao.gao@xxxxxxxxx> 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?

Roger.

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