linux-kernel - [pci PATCH v5 2/4] virtio_pci: Add support for unmanaged SR-IOV on virtio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180312172136.3487.95702.stgit@localhost.localdomain>
Date:   Mon, 12 Mar 2018 10:23:02 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     bhelgaas@...gle.com, alexander.h.duyck@...el.com,
        linux-pci@...r.kernel.org
Cc:     virtio-dev@...ts.oasis-open.org, kvm@...r.kernel.org,
        netdev@...r.kernel.org, dan.daly@...el.com,
        linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
        keith.busch@...el.com, netanel@...zon.com, mheyne@...zon.de,
        liang-min.wang@...el.com, mark.d.rustad@...el.com,
        dwmw2@...radead.org, hch@....de, dwmw@...zon.co.uk
Subject: [pci PATCH v5 2/4] virtio_pci: Add support for unmanaged SR-IOV on
 virtio_pci devices

From: Alexander Duyck <alexander.h.duyck@...el.com>

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.

Signed-off-by: Mark Rustad <mark.d.rustad@...el.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@...el.com>
---

v4: Dropped call to pci_disable_sriov in virtio_pci_remove function
v5: Replaced call to pci_sriov_configure_unmanaged with
        pci_sriov_configure_simple

 drivers/virtio/virtio_pci_common.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c
index 48d4d1cf1cb6..41938d36b0cb 100644
--- a/drivers/virtio/virtio_pci_common.c
+++ b/drivers/virtio/virtio_pci_common.c
@@ -596,6 +596,9 @@ static void virtio_pci_remove(struct pci_dev *pci_dev)
 #ifdef CONFIG_PM_SLEEP
 	.driver.pm	= &virtio_pci_pm_ops,
 #endif
+#ifdef CONFIG_PCI_IOV
+	.sriov_configure = pci_sriov_configure_simple,
+#endif
 };

 module_pci_driver(virtio_pci_driver);