[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v7] VT-d: use correct BDF for VF to search VT-d unit

>>> On 23.08.17 at 09:39, <chao.gao@xxxxxxxxx> wrote:
> On Wed, Aug 23, 2017 at 02:04:24AM -0600, Jan Beulich wrote:
>>>>> On 23.08.17 at 03:05, <chao.gao@xxxxxxxxx> wrote:
>>> Strictly speaking, the VF can be an extended function. The definition is
>>> within ARI device (in this kind of device, device field is treated as an
>>> extension of function number) and function number is greater than 7. But
>>> this field isn't used as we don't care about whether a VF is or not an
>>> extended function (at least at present).
>>Hmm, that's not in line with what Linux'es xen_add_device() does:
>>              if (pci_dev->is_virtfn) {
>>                      add->flags = XEN_PCI_DEV_VIRTFN;
>>                      add->physfn.bus = physfn->bus->number;
>>                      add->physfn.devfn = physfn->devfn;
>>              } else
>>              if (pci_ari_enabled(pci_dev->bus) && PCI_SLOT(pci_dev->devfn))
>>                      add->flags = XEN_PCI_DEV_EXTFN;
>>Note the "else" in there. Are you saying this is actually wrong? (I
>>indeed do see ARI capability structures in the VFs of the one
>>SR-IOV capable system I have direct access to.)
> Yes. I think it is wrong. Considering no one in Xen needs this
> information, don't set XEN_PCI_DEV_EXTFN for VF is acceptable.

Well, that's the current situation. However, the information Dom0
reports to Xen should be correct, i.e. someone may at some point
decide to fix the code above. That would then collide with your
re-use of the is_extfn field in Xen, which then suddenly would be
set by other than what your patch arranges for.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.