Hi Laine,
Did you have a bug for this issue?
I need it to document it in for my workaround in OpenStack.
Thanks,
Moshe Levi.
-----Original Message-----
From: Daniel P. Berrange [mailto:berrange@redhat.com]
Sent: Monday, November 23, 2015 6:29 PM
To: Laine Stump <laine(a)laine.org>
Cc: libvir-list(a)redhat.com; Moshe Levi <moshele(a)mellanox.com>
Subject: Re: [libvirt] how to know if PCI device has SR-IOV PF capability
On Mon, Nov 23, 2015 at 11:26:11AM -0500, Laine Stump wrote:
> On 11/23/2015 10:40 AM, Daniel P. Berrange wrote:
> >On Mon, Nov 23, 2015 at 10:34:43AM -0500, Laine Stump wrote:
> >
> >>If we're going to switch to emiting virt_functions whenever a device
> >>has the potential to provide VFs, we may as well make it worthwhile
> >>and also emit the maximum possible VFs for the device, maybe simply:
> >>
> >> <capability type='virt_functions' maxCount='7'>
> >>
> >>(the current count is implicit in the number of entries in the list
> >>that follows. I don't have an opinion on whether it is better to
> >>also include explicitly with, e.g. "count='7'", or just
leave it implicit).
> >Is there any way for us to actually discover the max count ? If so,
> >then it seems nice to include it.
>
> Yes. I don't know if it existed back when that code was originally
> added, but at least RHEL6.7 (the oldest OS I have running on a machine
> with an SRIOV-capable card) and later have two files in the device's
> sysfs, sriov_numvfs and sriov_totalvfs. The former is the number that
> are currently active, and the latter is the maximum possible for this PF.
>
> (On a related topic - you can change the number of currently active
> VFs by writing "0" to sriov_numvfs then writing the desired number to
> it; this does temporarily delete any VFs that are already active
> though, so it can only be done if none are in use. I've planned to
> hook libvirt networks up to this so that VFs can be enabled completely
> within libvirt (since the driver commandline method isn't consistent
> between different vendors, and I believe is now considered to be
> deprecated). Since Openstack doesn't use libvirt networks but may want
> similar functionality, I'm wondering where would be a good place to do
> that. We could provide something via the node-device API, but that
> couldn't be automatically done by libvirtd at startup; alternately
> Openstack could create a network but not use it, but that just seems
> conceptually confusing even though it would work.)
There is scope to extend node device APIs to allow definition of persistent
config for virtual devices. We have similar scenario wrt NPIV devices which are
dynamically allocatable
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|