From: kbuild test robot <lkp@intel.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: kbuild-all@01.org, bhelgaas@google.com,
alexander.h.duyck@intel.com, linux-pci@vger.kernel.org,
virtio-dev@lists.oasis-open.org, kvm@vger.kernel.org,
netdev@vger.kernel.org, dan.daly@intel.com,
linux-kernel@vger.kernel.org, mheyne@amazon.de,
liang-min.wang@intel.com, mark.d.rustad@intel.com,
dwmw2@infradead.org, dwmw@amazon.co.uk
Subject: Re: [PATCH 2/3] vfio: Add support for unmanaged or userspace managed SR-IOV
Date: Tue, 6 Mar 2018 12:49:15 +0800 [thread overview]
Message-ID: <201803061207.6CTs3ijg%fengguang.wu@intel.com> (raw)
In-Reply-To: <20180302234432.3337.96123.stgit@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 3594 bytes --]
Hi Alexander,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on v4.16-rc4 next-20180305]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Alexander-Duyck/pci-iov-Add-support-for-unmanaged-SR-IOV/20180306-063954
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: s390-default_defconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390
All errors (new ones prefixed by >>):
drivers/vfio/pci/vfio_pci.c: In function 'vfio_pci_sriov_configure':
>> drivers/vfio/pci/vfio_pci.c:1291:8: error: implicit declaration of function 'pci_sriov_configure_unmanaged'; did you mean 'pci_write_config_dword'? [-Werror=implicit-function-declaration]
err = pci_sriov_configure_unmanaged(pdev, nr_virtfn);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pci_write_config_dword
At top level:
drivers/vfio/pci/vfio_pci.c:1265:12: warning: 'vfio_pci_sriov_configure' defined but not used [-Wunused-function]
static int vfio_pci_sriov_configure(struct pci_dev *pdev, int nr_virtfn)
^~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +1291 drivers/vfio/pci/vfio_pci.c
1264
1265 static int vfio_pci_sriov_configure(struct pci_dev *pdev, int nr_virtfn)
1266 {
1267 struct vfio_pci_device *vdev;
1268 struct vfio_device *device;
1269 int err;
1270
1271 device = vfio_device_get_from_dev(&pdev->dev);
1272 if (device == NULL)
1273 return -ENODEV;
1274
1275 vdev = vfio_device_data(device);
1276 if (vdev == NULL) {
1277 vfio_device_put(device);
1278 return -ENODEV;
1279 }
1280
1281 /*
1282 * If a userspace process is already using this device just return
1283 * busy and don't allow for any changes.
1284 */
1285 if (vdev->refcnt) {
1286 pci_warn(pdev,
1287 "PF is currently in use, blocked until released by user\n");
1288 return -EBUSY;
1289 }
1290
> 1291 err = pci_sriov_configure_unmanaged(pdev, nr_virtfn);
1292 if (err <= 0)
1293 return err;
1294
1295 /*
1296 * We are now leaving VFs in the control of some unknown PF entity.
1297 *
1298 * Best case is a well behaved userspace PF is expected and any VMs
1299 * that the VFs will be assigned to are dependent on the userspace
1300 * entity anyway. An example being NFV where maybe the PF is acting
1301 * as an accelerated interface for a firewall or switch.
1302 *
1303 * Worst case is somebody really messed up and just enabled SR-IOV
1304 * on a device they were planning to assign to a VM somwhere.
1305 *
1306 * In either case it is probably best for us to set the taint flag
1307 * and warn the user since this could get really ugly really quick
1308 * if this wasn't what they were planning to do.
1309 */
1310 add_taint(TAINT_USER, LOCKDEP_STILL_OK);
1311 pci_warn(pdev,
1312 "Adding kernel taint for vfio-pci now managing SR-IOV PF device\n");
1313
1314 return nr_virtfn;
1315 }
1316
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 17664 bytes --]
next prev parent reply other threads:[~2018-03-06 4:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-02 23:44 [PATCH 0/3] pci-iov: Add support for unmanaged SR-IOV Alexander Duyck
2018-03-02 23:44 ` [PATCH 1/3] " Alexander Duyck
2018-03-02 23:59 ` Alex Williamson
2018-03-03 0:20 ` Alexander Duyck
2018-03-02 23:44 ` [PATCH 2/3] vfio: Add support for unmanaged or userspace managed SR-IOV Alexander Duyck
2018-03-06 4:49 ` kbuild test robot [this message]
2018-03-02 23:45 ` [PATCH 3/3] virtio_pci: Add support for unmanaged SR-IOV on virtio_pci devices Alexander Duyck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201803061207.6CTs3ijg%fengguang.wu@intel.com \
--to=lkp@intel.com \
--cc=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=bhelgaas@google.com \
--cc=dan.daly@intel.com \
--cc=dwmw2@infradead.org \
--cc=dwmw@amazon.co.uk \
--cc=kbuild-all@01.org \
--cc=kvm@vger.kernel.org \
--cc=liang-min.wang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mark.d.rustad@intel.com \
--cc=mheyne@amazon.de \
--cc=netdev@vger.kernel.org \
--cc=virtio-dev@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®