From: Jason Gunthorpe <jgg@nvidia.com>
To: Diana Craciun OSS <diana.craciun@oss.nxp.com>
Cc: David Airlie <airlied@linux.ie>,
Tony Krowiak <akrowiak@linux.ibm.com>,
Alex Williamson <alex.williamson@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
Jonathan Corbet <corbet@lwn.net>, Daniel Vetter <daniel@ffwll.ch>,
dri-devel@lists.freedesktop.org,
Eric Auger <eric.auger@redhat.com>,
Eric Farman <farman@linux.ibm.com>,
Harald Freudenberger <freude@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
intel-gfx@lists.freedesktop.org,
intel-gvt-dev@lists.freedesktop.org,
Jani Nikula <jani.nikula@linux.intel.com>,
Jason Herne <jjherne@linux.ibm.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
kvm@vger.kernel.org, Kirti Wankhede <kwankhede@nvidia.com>,
linux-doc@vger.kernel.org, linux-s390@vger.kernel.org,
Matthew Rosato <mjrosato@linux.ibm.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
Halil Pasic <pasic@linux.ibm.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Vineeth Vijayan <vneethv@linux.ibm.com>,
Zhenyu Wang <zhenyuw@linux.intel.com>,
Zhi Wang <zhi.a.wang@intel.com>,
"Raj, Ashok" <ashok.raj@intel.com>,
Christoph Hellwig <hch@lst.de>,
Leon Romanovsky <leonro@nvidia.com>,
Max Gurtovoy <mgurtovoy@nvidia.com>,
Yishai Hadas <yishaih@nvidia.com>
Subject: Re: [PATCH 05/13] vfio/fsl: Move to the device set infrastructure
Date: Tue, 20 Jul 2021 13:17:13 -0300 [thread overview]
Message-ID: <20210720161713.GB1117491@nvidia.com> (raw)
In-Reply-To: <44639398-d50f-ac6a-d52b-4e964465ca6f@oss.nxp.com>
On Tue, Jul 20, 2021 at 07:12:26PM +0300, Diana Craciun OSS wrote:
> On 7/15/2021 3:20 AM, Jason Gunthorpe wrote:
> > FSL uses the internal reflck to implement the open_device() functionality,
> > conversion to the core code is straightforward.
> >
> > The decision on which set to be part of is trivially based on the
> > is_fsl_mc_bus_dprc() and we use a 'struct device *' pointer as the set_id.
> >
> > It isn't entirely clear what the device set lock is actually protecting,
> > but I think it is related to the interrupt setup.
>
> Yes, it is protecting the interrupts setup. The FSL MC devices are using
> MSIs and only the DPRC device is allocating the MSIs from the MSI domain.
> The other devices just take interrupts from a pool. The lock is protecting
> the access to this pool.
It would be much clearer if the lock was near the data it was
protecting, the DPRC pool seems in an entirely different layer..
> > -static void vfio_fsl_mc_release(struct vfio_device *core_vdev)
> > +static void vfio_fsl_mc_close_device(struct vfio_device *core_vdev)
> > {
> > struct vfio_fsl_mc_device *vdev =
> > container_of(core_vdev, struct vfio_fsl_mc_device, vdev);
> > + struct fsl_mc_device *mc_dev = vdev->mc_dev;
> > + struct device *cont_dev = fsl_mc_cont_dev(&mc_dev->dev);
> > + struct fsl_mc_device *mc_cont = to_fsl_mc_device(cont_dev);
> > int ret;
> > - mutex_lock(&vdev->reflck->lock);
> > + vfio_fsl_mc_regions_cleanup(vdev);
> > - if (!(--vdev->refcnt)) {
> > - struct fsl_mc_device *mc_dev = vdev->mc_dev;
> > - struct device *cont_dev = fsl_mc_cont_dev(&mc_dev->dev);
> > - struct fsl_mc_device *mc_cont = to_fsl_mc_device(cont_dev);
> > -
> > - vfio_fsl_mc_regions_cleanup(vdev);
> > + /* reset the device before cleaning up the interrupts */
> > + ret = dprc_reset_container(mc_cont->mc_io, 0, mc_cont->mc_handle,
> > + mc_cont->obj_desc.id,
> > + DPRC_RESET_OPTION_NON_RECURSIVE);
> > - /* reset the device before cleaning up the interrupts */
> > - ret = dprc_reset_container(mc_cont->mc_io, 0,
> > - mc_cont->mc_handle,
> > - mc_cont->obj_desc.id,
> > - DPRC_RESET_OPTION_NON_RECURSIVE);
> > + if (WARN_ON(ret))
> > + dev_warn(&mc_cont->dev,
> > + "VFIO_FLS_MC: reset device has failed (%d)\n", ret);
> > - if (ret) {
> > - dev_warn(&mc_cont->dev, "VFIO_FLS_MC: reset device has failed (%d)\n",
> > - ret);
> > - WARN_ON(1);
> > - }
> > + vfio_fsl_mc_irqs_cleanup(vdev);
> > - vfio_fsl_mc_irqs_cleanup(vdev);
> > -
> > - fsl_mc_cleanup_irq_pool(mc_cont);
>
> There is also a need for the lock here. Eventhough the close function is
> called only once, there might be a race between the devices in the
> set.
vfio_fsl_mc_close_device() is already called under this lock:
mutex_lock(&device->dev_set->lock);
if (!--device->open_count && device->ops->close_device)
device->ops->close_device(device);
mutex_unlock(&device->dev_set->lock);
Thanks,
Jason
next prev parent reply other threads:[~2021-07-20 16:22 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-15 0:20 [PATCH 00/13] Provide core infrastructure for managing open/release Jason Gunthorpe
2021-07-15 0:20 ` [PATCH 01/13] vfio/samples: Remove module get/put Jason Gunthorpe
2021-07-19 11:42 ` Cornelia Huck
2021-07-15 0:20 ` [PATCH 02/13] vfio: Introduce a vfio_uninit_group_dev() API call Jason Gunthorpe
2021-07-15 3:49 ` Leon Romanovsky
2021-07-15 12:45 ` Jason Gunthorpe
2021-07-19 12:11 ` Cornelia Huck
2021-07-19 12:17 ` Jason Gunthorpe
2021-07-19 12:43 ` Cornelia Huck
2021-07-15 0:20 ` [PATCH 03/13] vfio: Provide better generic support for open/release vfio_device_ops Jason Gunthorpe
2021-07-19 12:58 ` Cornelia Huck
2021-07-19 13:01 ` Jason Gunthorpe
2021-07-19 13:03 ` Jason Gunthorpe
2021-07-15 0:20 ` [PATCH 04/13] vfio/samples: Delete useless open/close Jason Gunthorpe
2021-07-19 13:01 ` Cornelia Huck
2021-07-15 0:20 ` [PATCH 05/13] vfio/fsl: Move to the device set infrastructure Jason Gunthorpe
2021-07-20 16:12 ` Diana Craciun OSS
2021-07-20 16:17 ` Jason Gunthorpe [this message]
2021-07-20 16:23 ` Diana Craciun OSS
2021-07-20 16:25 ` Jason Gunthorpe
2021-07-15 0:20 ` [PATCH 06/13] vfio/platform: Use open_device() instead of open coding a refcnt scheme Jason Gunthorpe
2021-07-15 0:20 ` [PATCH 07/13] vfio/pci: Move to the device set infrastructure Jason Gunthorpe
2021-07-15 0:20 ` [PATCH 08/13] vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set Jason Gunthorpe
2021-07-15 0:20 ` [PATCH 09/13] vfio/pci: Reorganize VFIO_DEVICE_PCI_HOT_RESET to use the device set Jason Gunthorpe
2021-07-15 21:00 ` Alex Williamson
2021-07-15 22:11 ` Jason Gunthorpe
2021-07-15 22:27 ` Alex Williamson
2021-07-15 0:20 ` [PATCH 10/13] vfio/mbochs: Fix close when multiple device FDs are open Jason Gunthorpe
2021-07-19 14:45 ` Cornelia Huck
2021-07-15 0:20 ` [PATCH 11/13] vfio/ap,ccw: Fix open/close " Jason Gunthorpe
2021-07-19 14:40 ` Cornelia Huck
2021-07-15 0:20 ` [PATCH 12/13] vfio/gvt: " Jason Gunthorpe
2021-07-16 6:50 ` Zhenyu Wang
2021-07-19 14:47 ` Cornelia Huck
2021-07-15 0:20 ` [PATCH 13/13] vfio: Remove struct vfio_device_ops open/release Jason Gunthorpe
2021-07-15 13:28 ` [PATCH 00/13] Provide core infrastructure for managing open/release Kirti Wankhede
2021-07-15 14:55 ` 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=20210720161713.GB1117491@nvidia.com \
--to=jgg@nvidia.com \
--cc=airlied@linux.ie \
--cc=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=corbet@lwn.net \
--cc=daniel@ffwll.ch \
--cc=diana.craciun@oss.nxp.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric.auger@redhat.com \
--cc=farman@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hch@lst.de \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jjherne@linux.ibm.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=leonro@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mgurtovoy@nvidia.com \
--cc=mjrosato@linux.ibm.com \
--cc=oberpar@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=rodrigo.vivi@intel.com \
--cc=vneethv@linux.ibm.com \
--cc=yishaih@nvidia.com \
--cc=zhenyuw@linux.intel.com \
--cc=zhi.a.wang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).