[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190319162712.37f804f8@oc2783563651>
Date: Tue, 19 Mar 2019 16:27:12 +0100
From: Halil Pasic <pasic@...ux.ibm.com>
To: Pierre Morel <pmorel@...ux.ibm.com>
Cc: borntraeger@...ibm.com, alex.williamson@...hat.com,
cohuck@...hat.com, linux-kernel@...r.kernel.org,
linux-s390@...r.kernel.org, kvm@...r.kernel.org,
frankja@...ux.ibm.com, akrowiak@...ux.ibm.com, david@...hat.com,
schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
freude@...ux.ibm.com, mimu@...ux.ibm.com
Subject: Re: [PATCH v5 4/7] s390: ap: setup relation betwen KVM and mediated
device
On Tue, 19 Mar 2019 15:47:05 +0100
Pierre Morel <pmorel@...ux.ibm.com> wrote:
> >>>>> if (matrix_mdev->kvm)
> >>>>> kvm_arch_crypto_clear_masks(matrix_mdev->kvm);
> >>>>
> >>>> This still conditional?
> >>>
> >>> Yes, nothing to clear if there is no KVM.
> >>>
> >>
> >> Since we have ensured the open only works if there is a KVM at that
> >> point in time, and we have taken a reference to KVM, I would expect
> >> KVM can not go away before we give up our reference.
> >
> > Right.
>
> Right but based on the assumption we do a kvm_get_kvm() during open.
>
> But now we will do it inside the notifier, so the logic is to do a
> kvm_put_kvm in the notifier too.
> This is important because userland will ask us to release the KVM/VFIO
> link through this notifier.
> So I will have to rework this part where KVM==NULL in the notifier too.
>
> Regards,
> Pierre
I think it can be done both ways. If you ensure KVM != NULL if the open
succeeds and take the reference in the notifier. I suppose if open()
fails release() won't be called. But the logic/code in open() would get
quite ugly because the callback could be called assync so that it
overlaps with the rest of open().
Not failing open() in case of no KVM is there yet is in my opinion
cleaner anyway.
Regards,
Halil
Powered by blists - more mailing lists