Open Stack

Hi all,

In the current SR-IOV implementation there is a check in Nova (specifically _get_device_type in nova/virt/libvirt/driver.py) that determines if a given PCI device is:

- a normal PCI device,
- an SR-IOV physical function (PF); or
- an SR-IOV virtual function (VF).

If it's a normal PCI device or a virtual function it's considered fair game for passthrough, if it's a PF it's not (considered to be owned by the host). There are two things I am a little unclear on and was hoping someone might be able to help me understand:

1) If the device is a "normal" PCI device, but is a network card, am I still able to take advantage of the advanced syntax added circa Juno to define the relationship between that card and a given physical network so that the scheduler can place accordingly (and does this still use the ML2 mech drvier for SR-IOV even though it's a "normal" device.

2) There is no functional reason from a Libvirt/Qemu perspective that I couldn't pass through a PF to a guest, and some users have expressed surprise to me when they have run into this check in the Nova driver. I assume in the initial implementation this was prevented to avoid a whole heap of fun additional logic that is required if this is allowed (e.g. check that no VFs from the PF being requested are already in use, remove all the associated VFs from the pool when assigning the PF, who gets allowed to use PFs versus VFs etc.). Am I correct here or is there another reason that this would be undesirable to allow in future - assuming such checks can also be designed - that I am missing?

Thanks,

Steve