Re: [Xen-devel] [patch v6] vt-d: fix vf of rc integrated pf matched to wrong vt-d unit

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

On Wed, Aug 16, 2017 at 04:50:51PM +0800, Chao Gao wrote:
> On Wed, Aug 16, 2017 at 09:17:46AM +0100, Roger Pau Monné wrote:
> >on wed, aug 16, 2017 at 01:12:24pm +0800, chao gao wrote:
> >> the problem is for a vf of rc integrated pf (e.g. pf's bdf is
> >> 00:02.0), we would wrongly use 00:00.0 to search vt-d unit.
> >> 
> >> 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 is
> >> greater than 7.
> >
> >AFAIK, extended functions simply remove the slot and extend the
> >function number to [0, 255], so it seems correct to expect that the
> >VT-d unit search should be done using the bus and extended function
> >parameters, and assume slot is 0. Is this some kind of limitation of
> >VT-d?
> 
> VT-d spec makes such provision for VT-d unit search without any
> explaination. But I think it isn't. Whether we can find the right VT-d unit
> depends on DMAR. So I would rather regard it as firmware doesn't prepare
> entries for extended functions in DMAR.

Looking again at the proposed changes in acpi_find_matched_drhd_unit,
it seems fine. If the VF belongs to a PF that uses extended functions
just use 0 as devfn, which is the devfn of the PF itself unless I'm
mistaken. It's just that I find the commit log very hard to
parse/understand.

Roger.

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