On Tue, 31 Jul 2018 15:12:59 +0200
Halil Pasic <pasic@xxxxxxxxxxxxx> wrote:
> On 07/31/2018 02:24 PM, Cornelia Huck wrote:
> >> +static int vfio_ap_mdev_reset_queues(struct mdev_device *mdev, bool force)
> >> +{
> >> + int ret;
> >> + int rc = 0;
> >> + unsigned long apid, apqi;
> >> + struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
> >> +
> >> + if (!matrix_mdev->activated) {
> >> + pr_err("%s: reset failed for mdev %s, not activated",
> >> + VFIO_AP_MODULE_NAME, matrix_mdev->name);
> >> +
> >> + return -EPERM;
> >> + }
> > Hm... if we stick with the activation approach, what happens if we:
> > - open the mdev
> > - activate the matrix
> > - deactivate the matrix
>
> I guess this step will fail and the matrix remains activated.
>
> Have a look at vfio_ap_mdev_deactivate()
Hm, I don't see it...
>
> > - release the mdev, triggering this function
> >
> > It seems we won't call PAPQ(ZAPQ) in that case -- is that how it is
> > supposed to work?
> >
>
> So basically the device remains active until the mdev release is
> called if I'm correct.
So, why do we need the activate/deactivate approach, then? Why can't we
do the verification etc. during open?
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
