>>> On 23.08.17 at 09:39, <chao....@intel.com> wrote:
> On Wed, Aug 23, 2017 at 02:04:24AM -0600, Jan Beulich wrote:
>>>>> On 23.08.17 at 03:05, <chao....@intel.com> 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:
>>
>>#ifdef CONFIG_PCI_IOV
>> if (pci_dev->is_virtfn) {
>> add->flags = XEN_PCI_DEV_VIRTFN;
>> add->physfn.bus = physfn->bus->number;
>> add->physfn.devfn = physfn->devfn;
>> } else
>>#endif
>> 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.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
