On Tue, Apr 03, 2018 at 10:32:00AM -0700, Alexander Duyck wrote: > On Tue, Apr 3, 2018 at 6:12 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Fri, Mar 16, 2018 at 09:40:34AM -0700, Alexander Duyck wrote: > >> On Fri, Mar 16, 2018 at 9:34 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > >> > On Thu, Mar 15, 2018 at 11:42:41AM -0700, Alexander Duyck wrote: > >> >> From: Alexander Duyck <alexander.h.duyck@xxxxxxxxx> > >> >> > >> >> Hardware-realized virtio_pci devices can implement SR-IOV, so this > >> >> patch enables its use. The device in question is an upcoming Intel > >> >> NIC that implements both a virtio_net PF and virtio_net VFs. These > >> >> are hardware realizations of what has been up to now been a software > >> >> interface. > >> >> > >> >> The device in question has the following 4-part PCI IDs: > >> >> > >> >> PF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 15fe > >> >> VF: vendor: 1af4 device: 1041 subvendor: 8086 subdevice: 05fe > >> >> > >> >> The patch currently needs no check for device ID, because the callback > >> >> will never be made for devices that do not assert the capability or > >> >> when run on a platform incapable of SR-IOV. > >> >> > >> >> One reason for this patch is because the hardware requires the > >> >> vendor ID of a VF to be the same as the vendor ID of the PF that > >> >> created it. So it seemed logical to simply have a fully-functioning > >> >> virtio_net PF create the VFs. This patch makes that possible. > >> >> > >> >> Reviewed-by: Christoph Hellwig <hch@xxxxxx> > >> >> Signed-off-by: Mark Rustad <mark.d.rustad@xxxxxxxxx> > >> >> Signed-off-by: Alexander Duyck <alexander.h.duyck@xxxxxxxxx> > >> > > >> > So if and when virtio PFs can manage the VFs, then we can > >> > add a feature bit for that? > >> > Seems reasonable. > >> > >> Yes. If nothing else you may not even need a feature bit depending on > >> how things go. > > > > OTOH if the interface is changed in an incompatible way, > > and old Linux will attempt to drive the new device > > since there is no check. > > > > I think we should add a feature bit right away. > > I'm not sure why you would need a feature bit. The capability is > controlled via PCI configuration space. If it is present the device > has the capability. If it is not then it does not. > > Basically if the PCI configuration space is not present then the sysfs > entries will not be spawned and nothing will attempt to use this > function. > > - ALex It's about compability with older guests which ignore the capability. The feature is thus helpful so host knows whether guest supports VFs. -- MSR
