From: Christoph Hellwig <hch@lst.de>
To: Max Gurtovoy <mgurtovoy@nvidia.com>
Cc: jgg@nvidia.com, alex.williamson@redhat.com, cohuck@redhat.com,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
liranl@nvidia.com, oren@nvidia.com, tzahio@nvidia.com,
leonro@nvidia.com, yarong@nvidia.com, aviadye@nvidia.com,
shahafs@nvidia.com, artemp@nvidia.com, kwankhede@nvidia.com,
ACurrid@nvidia.com, cjia@nvidia.com, yishaih@nvidia.com,
mjrosato@linux.ibm.com, aik@ozlabs.ru, hch@lst.de
Subject: Re: [PATCH 9/9] vfio/pci: export igd support into vendor vfio_pci driver
Date: Wed, 10 Mar 2021 09:15:08 +0100 [thread overview]
Message-ID: <20210310081508.GB4364@lst.de> (raw)
In-Reply-To: <20210309083357.65467-10-mgurtovoy@nvidia.com>
The terminology is all weird here. You don't export functionality
you move it. And this is not a "vendor" driver, but just a device
specific one.
> +struct igd_vfio_pci_device {
> + struct vfio_pci_core_device vdev;
> +};
Why do you need this separate structure? You could just use
vfio_pci_core_device directly.
> +static void igd_vfio_pci_release(void *device_data)
> +{
> + struct vfio_pci_core_device *vdev = device_data;
> +
> + mutex_lock(&vdev->reflck->lock);
> + if (!(--vdev->refcnt)) {
No need for the braces here.
> + vfio_pci_vf_token_user_add(vdev, -1);
> + vfio_pci_core_spapr_eeh_release(vdev);
> + vfio_pci_core_disable(vdev);
> + }
> + mutex_unlock(&vdev->reflck->lock);
But more importantly all this code should be in a helper exported
from the core code.
> +
> + module_put(THIS_MODULE);
This looks bogus - the module reference is now gone while
igd_vfio_pci_release is still running. Module refcounting always
need to be done by the caller, not the individual driver.
> +static int igd_vfio_pci_open(void *device_data)
> +{
> + struct vfio_pci_core_device *vdev = device_data;
> + int ret = 0;
> +
> + if (!try_module_get(THIS_MODULE))
> + return -ENODEV;
Same here - thi is something the caller needs to do.
> + mutex_lock(&vdev->reflck->lock);
> +
> + if (!vdev->refcnt) {
> + ret = vfio_pci_core_enable(vdev);
> + if (ret)
> + goto error;
> +
> + ret = vfio_pci_igd_init(vdev);
> + if (ret && ret != -ENODEV) {
> + pci_warn(vdev->pdev, "Failed to setup Intel IGD regions\n");
> + vfio_pci_core_disable(vdev);
> + goto error;
> + }
> + ret = 0;
> + vfio_pci_probe_mmaps(vdev);
> + vfio_pci_core_spapr_eeh_open(vdev);
> + vfio_pci_vf_token_user_add(vdev, 1);
Way to much boilerplate. Why doesn't the core only call a function
that does the vfio_pci_igd_init?
> +static const struct pci_device_id igd_vfio_pci_table[] = {
> + { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_DISPLAY_VGA << 8, 0xff0000, 0 },
Please avoid the overly long line. And a match as big as any Intel
graphics at very least needs a comment documenting why this is safe
and will perpetually remain safe.
> +#ifdef CONFIG_VFIO_PCI_DRIVER_COMPAT
> +struct pci_driver *get_igd_vfio_pci_driver(struct pci_dev *pdev)
> +{
> + if (pci_match_id(igd_vfio_pci_driver.id_table, pdev))
> + return &igd_vfio_pci_driver;
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(get_igd_vfio_pci_driver);
> +#endif
> + case PCI_VENDOR_ID_INTEL:
> + if (pdev->class == PCI_CLASS_DISPLAY_VGA << 8)
> + return get_igd_vfio_pci_driver(pdev);
And this now means that the core code has a dependency on the igd
one, making the whole split rather pointless.
next prev parent reply other threads:[~2021-03-10 8:16 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-09 8:33 [PATCH v3 0/9] Introduce vfio-pci-core subsystem Max Gurtovoy
2021-03-09 8:33 ` [PATCH 1/9] vfio-pci: rename vfio_pci.c to vfio_pci_core.c Max Gurtovoy
2021-03-09 8:33 ` [PATCH 2/9] vfio-pci: rename vfio_pci_private.h to vfio_pci_core.h Max Gurtovoy
2021-03-09 8:33 ` [PATCH 3/9] vfio-pci: rename vfio_pci_device to vfio_pci_core_device Max Gurtovoy
2021-03-09 8:33 ` [PATCH 4/9] vfio-pci: introduce vfio_pci_core subsystem driver Max Gurtovoy
2021-03-09 8:33 ` [PATCH 5/9] vfio/pci: introduce vfio_pci_device structure Max Gurtovoy
2021-03-09 8:33 ` [PATCH 6/9] vfio-pci-core: export vfio_pci_register_dev_region function Max Gurtovoy
2021-03-09 8:33 ` [PATCH 7/9] vfio/pci_core: split nvlink2 to nvlink2gpu and npu2 Max Gurtovoy
2021-03-10 8:08 ` Christoph Hellwig
2021-03-09 8:33 ` [PATCH 8/9] vfio/pci: export nvlink2 support into vendor vfio_pci drivers Max Gurtovoy
2021-03-10 6:39 ` Alexey Kardashevskiy
2021-03-10 12:57 ` Max Gurtovoy
2021-03-10 13:02 ` Jason Gunthorpe
2021-03-10 14:24 ` Alexey Kardashevskiy
2021-03-10 19:40 ` Jason Gunthorpe
2021-03-11 1:20 ` Alexey Kardashevskiy
2021-03-11 1:34 ` Jason Gunthorpe
2021-03-11 1:42 ` Alexey Kardashevskiy
2021-03-11 2:00 ` Jason Gunthorpe
2021-03-11 7:54 ` Alexey Kardashevskiy
2021-03-11 9:44 ` Max Gurtovoy
2021-03-11 16:51 ` Jason Gunthorpe
2021-03-11 17:01 ` Jason Gunthorpe
2021-03-10 14:19 ` Alexey Kardashevskiy
2021-03-11 1:10 ` Max Gurtovoy
2021-03-19 15:23 ` Alex Williamson
2021-03-19 16:17 ` Jason Gunthorpe
2021-03-19 16:20 ` Christoph Hellwig
2021-03-19 16:28 ` Jason Gunthorpe
2021-03-19 16:34 ` Christoph Hellwig
2021-03-19 17:36 ` Alex Williamson
2021-03-19 20:07 ` Jason Gunthorpe
2021-03-19 21:08 ` Alex Williamson
2021-03-19 22:59 ` Jason Gunthorpe
2021-03-20 4:40 ` Alex Williamson
2021-03-21 12:58 ` Jason Gunthorpe
2021-03-22 16:40 ` Alex Williamson
2021-03-23 19:32 ` Jason Gunthorpe
2021-03-24 2:39 ` Alexey Kardashevskiy
2021-03-29 23:10 ` Alex Williamson
2021-04-01 13:04 ` Cornelia Huck
2021-04-01 13:12 ` Jason Gunthorpe
2021-04-01 21:49 ` Alex Williamson
2021-03-22 15:11 ` Christoph Hellwig
2021-03-22 16:44 ` Jason Gunthorpe
2021-03-23 13:17 ` Christoph Hellwig
2021-03-23 13:42 ` Jason Gunthorpe
2021-03-09 8:33 ` [PATCH 9/9] vfio/pci: export igd support into vendor vfio_pci driver Max Gurtovoy
2021-03-10 8:15 ` Christoph Hellwig [this message]
2021-03-10 12:31 ` Jason Gunthorpe
2021-03-11 11:37 ` Christoph Hellwig
2021-03-11 12:09 ` Max Gurtovoy
2021-03-11 15:43 ` Jason Gunthorpe
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=20210310081508.GB4364@lst.de \
--to=hch@lst.de \
--cc=ACurrid@nvidia.com \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=artemp@nvidia.com \
--cc=aviadye@nvidia.com \
--cc=cjia@nvidia.com \
--cc=cohuck@redhat.com \
--cc=jgg@nvidia.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=leonro@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liranl@nvidia.com \
--cc=mgurtovoy@nvidia.com \
--cc=mjrosato@linux.ibm.com \
--cc=oren@nvidia.com \
--cc=shahafs@nvidia.com \
--cc=tzahio@nvidia.com \
--cc=yarong@nvidia.com \
--cc=yishaih@nvidia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.