From: Pierre Morel <pmorel@linux.ibm.com>
To: Tony Krowiak <akrowiak@linux.ibm.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Cc: freude@linux.ibm.com, borntraeger@de.ibm.com, cohuck@redhat.com,
frankja@linux.ibm.com, david@redhat.com, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, pasic@linux.ibm.com,
alex.williamson@redhat.com, kwankhede@nvidia.com
Subject: Re: [PATCH v2 4/7] s390: vfio-ap: allow assignment of unavailable AP resources to mdev device
Date: Mon, 6 May 2019 09:05:07 +0200 [thread overview]
Message-ID: <2ba0aa01-e043-0013-4e2e-ea17bf9eea05@linux.ibm.com> (raw)
In-Reply-To: <1556918073-13171-5-git-send-email-akrowiak@linux.ibm.com>
On 03/05/2019 23:14, Tony Krowiak wrote:
> The AP architecture does not preclude assignment of AP resources that are
> not yet in the AP configuration (i.e., not available or not online).
> Let's go ahead and implement this facet of the AP architecture for linux
> guests.
>
> The current implementation does not allow assignment of AP resources to
> an mdev device if the AP queue devices identified by the assignment are
> not bound to the vfio_ap device driver. This patch allows assignment of AP
> resources to the mdev device even if the AP queue devices are not bound to
> the vfio_ap device driver, as long as the AP queue devices are not
> reserved by the AP BUS for use by the zcrypt device drivers.
or another mediated device.
>
> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 231 ++++++++------------------------------
> 1 file changed, 44 insertions(+), 187 deletions(-)
>
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index 1021466cb661..ea24caf17a16 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -113,122 +113,6 @@ static struct attribute_group *vfio_ap_mdev_type_groups[] = {
> NULL,
> };
>
> -struct vfio_ap_queue_reserved {
> - unsigned long *apid;
> - unsigned long *apqi;
> - bool reserved;
> -};
> -
> -/**
> - * vfio_ap_has_queue
> - *
> - * @dev: an AP queue device
> - * @data: a struct vfio_ap_queue_reserved reference
> - *
> - * Flags whether the AP queue device (@dev) has a queue ID containing the APQN,
> - * apid or apqi specified in @data:
> - *
> - * - If @data contains both an apid and apqi value, then @data will be flagged
> - * as reserved if the APID and APQI fields for the AP queue device matches
> - *
> - * - If @data contains only an apid value, @data will be flagged as
> - * reserved if the APID field in the AP queue device matches
> - *
> - * - If @data contains only an apqi value, @data will be flagged as
> - * reserved if the APQI field in the AP queue device matches
> - *
> - * Returns 0 to indicate the input to function succeeded. Returns -EINVAL if
> - * @data does not contain either an apid or apqi.
> - */
> -static int vfio_ap_has_queue(struct device *dev, void *data)
> -{
> - struct vfio_ap_queue_reserved *qres = data;
> - struct ap_queue *ap_queue = to_ap_queue(dev);
> - ap_qid_t qid;
> - unsigned long id;
> -
> - if (qres->apid && qres->apqi) {
> - qid = AP_MKQID(*qres->apid, *qres->apqi);
> - if (qid == ap_queue->qid)
> - qres->reserved = true;
> - } else if (qres->apid && !qres->apqi) {
> - id = AP_QID_CARD(ap_queue->qid);
> - if (id == *qres->apid)
> - qres->reserved = true;
> - } else if (!qres->apid && qres->apqi) {
> - id = AP_QID_QUEUE(ap_queue->qid);
> - if (id == *qres->apqi)
> - qres->reserved = true;
> - } else {
> - return -EINVAL;
> - }
> -
> - return 0;
> -}
> -
> -/**
> - * vfio_ap_verify_queue_reserved
> - *
> - * @matrix_dev: a mediated matrix device
> - * @apid: an AP adapter ID
> - * @apqi: an AP queue index
> - *
> - * Verifies that the AP queue with @apid/@apqi is reserved by the VFIO AP device
> - * driver according to the following rules:
> - *
> - * - If both @apid and @apqi are not NULL, then there must be an AP queue
> - * device bound to the vfio_ap driver with the APQN identified by @apid and
> - * @apqi
> - *
> - * - If only @apid is not NULL, then there must be an AP queue device bound
> - * to the vfio_ap driver with an APQN containing @apid
> - *
> - * - If only @apqi is not NULL, then there must be an AP queue device bound
> - * to the vfio_ap driver with an APQN containing @apqi
> - *
> - * Returns 0 if the AP queue is reserved; otherwise, returns -EADDRNOTAVAIL.
> - */
> -static int vfio_ap_verify_queue_reserved(unsigned long *apid,
> - unsigned long *apqi)
> -{
> - int ret;
> - struct vfio_ap_queue_reserved qres;
> -
> - qres.apid = apid;
> - qres.apqi = apqi;
> - qres.reserved = false;
> -
> - ret = driver_for_each_device(&matrix_dev->vfio_ap_drv->driver, NULL,
> - &qres, vfio_ap_has_queue);
> - if (ret)
> - return ret;
> -
> - if (qres.reserved)
> - return 0;
> -
> - return -EADDRNOTAVAIL;
> -}
> -
> -static int
> -vfio_ap_mdev_verify_queues_reserved_for_apid(struct ap_matrix_mdev *matrix_mdev,
> - unsigned long apid)
> -{
> - int ret;
> - unsigned long apqi;
> - unsigned long nbits = matrix_mdev->matrix.aqm_max + 1;
> -
> - if (find_first_bit_inv(matrix_mdev->matrix.aqm, nbits) >= nbits)
> - return vfio_ap_verify_queue_reserved(&apid, NULL);
> -
> - for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm, nbits) {
> - ret = vfio_ap_verify_queue_reserved(&apid, &apqi);
> - if (ret)
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> /**
> * vfio_ap_mdev_verify_no_sharing
> *
> @@ -236,18 +120,26 @@ vfio_ap_mdev_verify_queues_reserved_for_apid(struct ap_matrix_mdev *matrix_mdev,
> * and AP queue indexes comprising the AP matrix are not configured for another
> * mediated device. AP queue sharing is not allowed.
> *
> - * @matrix_mdev: the mediated matrix device
> + * @mdev_apm: the mask identifying the adapters assigned to mdev
> + * @mdev_apm: the mask identifying the adapters assigned to mdev
> *
> * Returns 0 if the APQNs are not shared, otherwise; returns -EADDRINUSE.
> */
> -static int vfio_ap_mdev_verify_no_sharing(struct ap_matrix_mdev *matrix_mdev)
> +static int vfio_ap_mdev_verify_no_sharing(unsigned long *mdev_apm,
> + unsigned long *mdev_aqm)
> {
> struct ap_matrix_mdev *lstdev;
> DECLARE_BITMAP(apm, AP_DEVICES);
> DECLARE_BITMAP(aqm, AP_DOMAINS);
>
> list_for_each_entry(lstdev, &matrix_dev->mdev_list, node) {
> - if (matrix_mdev == lstdev)
> + /*
> + * If either of the input masks belongs to the mdev to which an
> + * AP resource is being assigned, then we don't need to verify
> + * that mdev's masks.
> + */
> + if ((mdev_apm == lstdev->matrix.apm) ||
> + (mdev_aqm == lstdev->matrix.aqm))
> continue;
Is it possible that mdev_apm and mdev_aqm do not belong to the same
mediated device?
...snip...
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
next prev parent reply other threads:[~2019-05-06 7:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-03 21:14 [PATCH v2 0/7] s390: vfio-ap: dynamic configuration support Tony Krowiak
2019-05-03 21:14 ` [PATCH v2 1/7] s390: vfio-ap: wait for queue empty on queue reset Tony Krowiak
2019-05-06 6:41 ` Pierre Morel
2019-05-06 19:37 ` Tony Krowiak
2019-05-07 8:10 ` Pierre Morel
2019-05-07 15:12 ` Tony Krowiak
2019-05-03 21:14 ` [PATCH v2 2/7] s390: vfio-ap: maintain a shadow of the guest's CRYCB Tony Krowiak
2019-05-06 6:49 ` Pierre Morel
2019-05-06 19:53 ` Tony Krowiak
2019-05-07 8:22 ` Pierre Morel
2019-05-07 15:15 ` Tony Krowiak
2019-05-03 21:14 ` [PATCH v2 3/7] s390: vfio-ap: sysfs interface to display guest CRYCB Tony Krowiak
2019-05-06 6:54 ` Pierre Morel
2019-05-06 19:55 ` Tony Krowiak
2019-05-03 21:14 ` [PATCH v2 4/7] s390: vfio-ap: allow assignment of unavailable AP resources to mdev device Tony Krowiak
2019-05-06 7:05 ` Pierre Morel [this message]
2019-05-06 20:35 ` Tony Krowiak
2019-05-03 21:14 ` [PATCH v2 5/7] s390: vfio-ap: allow hot plug/unplug of AP resources using " Tony Krowiak
2019-05-06 10:42 ` Pierre Morel
2019-05-06 20:39 ` Tony Krowiak
2019-05-03 21:14 ` [PATCH v2 6/7] s390: vfio-ap: handle bind and unbind of AP queue device Tony Krowiak
2019-05-06 10:55 ` Pierre Morel
2019-05-06 20:43 ` Tony Krowiak
2019-05-03 21:14 ` [PATCH v2 7/7] s390: vfio-ap: update documentation Tony Krowiak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ba0aa01-e043-0013-4e2e-ea17bf9eea05@linux.ibm.com \
--to=pmorel@linux.ibm.com \
--cc=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.ibm.com \
--cc=schwidefsky@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox