----- Original Message -----
> From: "Przemyslaw Czesnowicz" <przemyslaw.czesnow...@intel.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Hi
> > 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.
> Actually libvirt won't allow using "normal" PCI devices for network
> interfaces into VM.
> Following error is thrown by libvirt
> libvirtError: unsupported configuration: Interface type hostdev is currently
> supported on SR-IOV Virtual Functions only
> I don't know why libvirt prohibits that. But we should prohibit that on
> Openstack side as well.

This is true for hostdev"> style configuration, "normal" PCI devices are still 
valid in Libvirt for passthrough using <hostdev> though. The former having been 
specifically created for handling passthrough of VFs, the latter being the more 
generic passthrough functionality and what was used with the original PCI 
passthrough functionality introduced circa Havana.

I guess what I'm really asking in this particular question is what is the 
intersection of these two implementations - if any, as on face value it seems 
that to passthrough a physical PCI device I must use the older syntax and thus 
can't have the scheduler be aware of its external network connectivity.

> > 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?
> > 
> I think that is correct. But even if the additional logic was implemented  it
> wouldn't work because of how libvirt behaves currently.

Again though, in the code we have a distinction between a physical device (as I 
was asking about in Q1) and a physical function (as I am asking about in Q2) 
and similarly whether libvirt allows or not depends on how you configure in the 
guest XML. Though I wouldn't be surprised on the PF case if it is in fact not 
allowed in Libvirt (even with <hostdev>) it is again important to consider this 
distinctly separate from passing through the physical device case which we DO 
allow currently in the code I'm asking about.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to