On 7/26/21 6:43 PM, Halil Pasic wrote:
On Mon, 26 Jul 2021 19:03:17 -0300
Jason Gunthorpe <jgg@xxxxxxxxxx> 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.
Well if that is the case then provided your fix precedes this patch:
Acked-by: Halil Pasic <pasic@xxxxxxxxxxxxx>
I'm not entirely happy with this. I did not thoroughly investigate the
implications of reversing the locking order of the vfio-ap lock (driver
global) and the kvm lock (guest specific). I will trust Tony and hope
our KVM maintainers will scream if this is bad from interference and
delay perspective.
This solution was suggested by Jason G and it does in fact resolve
the lockdep splat encountered when starting an SE guest with
access to crypto resources. There is a chance that the KVM lock
can get held while waiting for the lock on the matrix_dev->mutex,
but this does not seem like a grave concern to me. That would
only happen during VFIO_GROUP_NOTIFY_SET_KVM notification - either
when the guest is being started or terminated, or when the mdev
fd is opened or closed. According to Jason, once he integrates his reflck
series, the open/close will happen only once.
I've copied the KVM maintainers on this response, so hopefully one of
them will provide some input.
Regards,
Halil
