* Re: [PATCH 2/2] s390/vfio-ap: replace open coded locks for VFIO_GROUP_NOTIFY_SET_KVM notification
[not found] ` <20210726220317.GA1721383@nvidia.com>
@ 2021-07-27 6:54 ` Christoph Hellwig
0 siblings, 0 replies; only message in thread
From: Christoph Hellwig @ 2021-07-27 6:54 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Halil Pasic, Tony Krowiak, linux-s390, linux-kernel, borntraeger,
cohuck, pasic, jjherne, alex.williamson, kwankhede, david, kvm
On Mon, Jul 26, 2021 at 07:03:17PM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 26, 2021 at 10:36:28PM +0200, Halil Pasic wrote:
>
> > You may end up with open and close running interleaved. What I'
> > trying to say is, to my best knowledge, normally there is no
> > you have to close it before you open it again rule for files.
>
> This is an existing bug in this driver, I've fixed in the reflck series.
>
> open_device/close_device will not run concurrently, or out of order,
> afer it is fixed.
Btw, while I've got all your attention, I've been struggling a bit with
how that SET_KVM notifier is supposed to work.
The i915 gvt code simplify assumes the notification registration hits
the case of KVM already being active, and gets away with that as at
least qemu ensures that the KVM_DEV_VFIO_GROUP_ADD has been called before
the device FDs are opened. Is that something we could generalize and
never allow to actually notify for SET_KVM with non-null data beeing
called at runtime and avoid the locking entirely?
Similarly the removal case is a little weird: with Jason's work to only
call a release function on the last reference drop which solves a lot
of concurrency issues nicely this still creates a nasty corner case
with a sideband release under weird locking rules. What prevents the
vfio core from simply holding a refefeence to the struct kvm as long as
the device is open to close that hole?
^ permalink raw reply [flat|nested] only message in thread