Comment 3 for bug 1841067

Hello:

First of all, let me set some limitations and conditions:
- We still support kernels < 3.13. That means "upper_macvtap" shouldn't be in the FS.
- As described in the bug, we need to remove the macvtap dependency to an administrative MAC in the VF under the macvtap NIC.

I think [1] goes in the good direction, with the exception of relaying on the FS to retrieve the macvtap, as done in the upper patch [2]. We still can't still check always the macvtap interface from the FS. Apart from this, I think the patch is correct:
- When retrieving the PCI device info ("get_pci_device"), there is a double check to try first to retrieve the VF information and then, if the first fails, the macvtap info.
- The code split between VF and macvtap ("is_assigned_vf_direct", "is_assigned_vf_macvtap") IMO is a good idea.
- In the macvtap leaf, we retrieve the device MAC in a different way by reading the macvtap device MAC instead of the VF mac (the main problem here!).

IMO, we should restore this patch, rebase it on top of master and continue working on it.

[1] https://review.opendev.org/#/c/676713/
[2] https://review.opendev.org/#/c/677095