On 07/31/2018 03:40 PM, Cornelia Huck wrote:
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...
static int vfio_ap_mdev_deactivate(struct ap_matrix_mdev *matrix_mdev)
{
int ret = 0;
if (!matrix_mdev->activated)
return 0;
if (matrix_mdev->kvm) {
pr_warn("%s: %s: deactivate failed, mdev %s is in use by guest %s\n",
VFIO_AP_MODULE_NAME, __func__, matrix_mdev->name,
matrix_mdev->kvm->arch.dbf->name);
return -EBUSY; <===================================== Return -EBUSY and don't deactivate.
}
matrix_mdev->activated = false;
return ret;
}
- 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?
We ca do the verification during open. If there was no activate before
the open we actually try to do one.
With activate however the admin can claim the resources before the
open (that is the guest start). We have a mechanism for both 'let's
overcommit and fail when we hit the wall' and 'let's make sure everything
is reserved before we give it to the guest'. The admin is free to
decide on his policy.
Please take note that activate also has an effect on the availability
of certain operations (e.g. assign/unassign).
Regards,
Halil
--
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
