All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason J. Herne" <jjherne@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,
	mjrosato@linux.ibm.com, pasic@linux.ibm.com,
	alex.williamson@redhat.com, kwankhede@nvidia.com,
	fiuczy@linux.ibm.com
Subject: Re: [PATCH v18 12/18] s390/vfio-ap: reset queues after adapter/domain unassignment
Date: Tue, 15 Mar 2022 10:13:51 -0400	[thread overview]
Message-ID: <6083d83b-6867-2525-fdd8-baccde1a599f@linux.ibm.com> (raw)
In-Reply-To: <20220215005040.52697-13-akrowiak@linux.ibm.com>

On 2/14/22 19:50, Tony Krowiak wrote:
> When an adapter or domain is unassigned from an mdev providing the AP
> configuration to a running KVM guest, one or more of the guest's queues may
> get dynamically removed. Since the removed queues could get re-assigned to
> another mdev, they need to be reset. So, when an adapter or domain is
> unassigned from the mdev, the queues that are removed from the guest's
> AP configuration will be reset.
> 
> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
> ---
...
>   
> +static void vfio_ap_unlink_apqn_fr_mdev(struct ap_matrix_mdev *matrix_mdev,
> +					unsigned long apid, unsigned long apqi,
> +					struct ap_queue_table *qtable)
> +{
> +	struct vfio_ap_queue *q;
> +
> +	q = vfio_ap_mdev_get_queue(matrix_mdev, AP_MKQID(apid, apqi));
> +	/* If the queue is assigned to the matrix mdev, unlink it. */
> +	if (q)
> +		vfio_ap_unlink_queue_fr_mdev(q);
> +
> +	/* If the queue is assigned to the APCB, store it in @qtable. */
> +	if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) &&
> +	    test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm))
> +		hash_add(qtable->queues, &q->mdev_qnode, q->apqn);
> +}
> +
> +/**
> + * vfio_ap_mdev_unlink_adapter - unlink all queues associated with unassigned
> + *				 adapter from the matrix mdev to which the
> + *				 adapter was assigned.
> + * @matrix_mdev: the matrix mediated device to which the adapter was assigned.
> + * @apid: the APID of the unassigned adapter.
> + * @qtable: table for storing queues associated with unassigned adapter.
> + */
>   static void vfio_ap_mdev_unlink_adapter(struct ap_matrix_mdev *matrix_mdev,
> -					unsigned long apid)
> +					unsigned long apid,
> +					struct ap_queue_table *qtable)
>   {
>   	unsigned long apqi;
> +
> +	for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm, AP_DOMAINS)
> +		vfio_ap_unlink_apqn_fr_mdev(matrix_mdev, apid, apqi, qtable);
> +}

Here is an alternate version of the above two functions that stops the
profileration of the qtables variable into vfio_ap_unlink_apqn_fr_mdev.
It may seem like a change with no benefit, but it simplifies things a
bit and avoids the reader from having to sink three functions deep to
find out where qtables is used. This is 100% untested.


static bool vfio_ap_unlink_apqn_fr_mdev(struct ap_matrix_mdev *matrix_mdev,
					unsigned long apid, unsigned long apqi)
{
	struct vfio_ap_queue *q;

	q = vfio_ap_mdev_get_queue(matrix_mdev, AP_MKQID(apid, apqi));
	/* If the queue is assigned to the matrix mdev, unlink it. */
	if (q) {
		vfio_ap_unlink_queue_fr_mdev(q);
		return true;
	}
	return false;
}

static void vfio_ap_mdev_unlink_adapter(struct ap_matrix_mdev *matrix_mdev,
					unsigned long apid,
					struct ap_queue_table *qtable)
{
	unsigned long apqi;
	bool unlinked;

	for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm, AP_DOMAINS) {
		unlinked = vfio_ap_unlink_apqn_fr_mdev(matrix_mdev, apid, apqi, qtable);

		if (unlinked && qtable) {
			if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm) &&
			    test_bit_inv(apqi, matrix_mdev->shadow_apcb.aqm))
				hash_add(qtable->queues, &q->mdev_qnode,
					 q->apqn);
		}
	}
}


> +static void vfio_ap_mdev_hot_unplug_adapter(struct ap_matrix_mdev *matrix_mdev,
> +					    unsigned long apid)
> +{
> +	int bkt;
>   	struct vfio_ap_queue *q;
> +	struct ap_queue_table qtable;
> +	hash_init(qtable.queues);
> +	vfio_ap_mdev_unlink_adapter(matrix_mdev, apid, &qtable);
> +
> +	if (test_bit_inv(apid, matrix_mdev->shadow_apcb.apm)) {
> +		clear_bit_inv(apid, matrix_mdev->shadow_apcb.apm);
> +		vfio_ap_mdev_hotplug_apcb(matrix_mdev);
> +	}
>   
> -	for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm, AP_DOMAINS) {
> -		q = vfio_ap_mdev_get_queue(matrix_mdev, AP_MKQID(apid, apqi));
> +	vfio_ap_mdev_reset_queues(&qtable);
>   
> -		if (q)
> -			vfio_ap_mdev_unlink_queue(q);
> +	hash_for_each(qtable.queues, bkt, q, mdev_qnode) {

This comment applies to all instances of btk: What is btk? Can we come
up with a more descriptive name?

> +		vfio_ap_unlink_mdev_fr_queue(q);
> +		hash_del(&q->mdev_qnode);
>   	}
>   }
...
> @@ -1273,9 +1320,9 @@ static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev,
>   		mutex_lock(&kvm->lock);
>   		mutex_lock(&matrix_dev->mdevs_lock);
>   
> -		kvm_arch_crypto_clear_masks(kvm);
> -		vfio_ap_mdev_reset_queues(matrix_mdev);
> -		kvm_put_kvm(kvm);
> +		kvm_arch_crypto_clear_masks(matrix_mdev->kvm);
> +		vfio_ap_mdev_reset_queues(&matrix_mdev->qtable);
> +		kvm_put_kvm(matrix_mdev->kvm);
>   		matrix_mdev->kvm = NULL;

I understand changing the call to vfio_ap_mdev_reset_queues, but why are we changing the
kvm pointer on the surrounding lines?

>   
>   		mutex_unlock(&matrix_dev->mdevs_lock);
> @@ -1328,14 +1375,17 @@ static int vfio_ap_mdev_reset_queue(struct vfio_ap_queue *q, unsigned int retry)
>   
>   	if (!q)
>   		return 0;
> +	q->reset_rc = 0;

This line seems unnecessary. You set q->reset_rc in every single case below, so this 0
will always get overwritten.

>   retry_zapq:
>   	status = ap_zapq(q->apqn);
>   	switch (status.response_code) {
>   	case AP_RESPONSE_NORMAL:
>   		ret = 0;
> +		q->reset_rc = status.response_code;
>   		break;
>   	case AP_RESPONSE_RESET_IN_PROGRESS:
> +		q->reset_rc = status.response_code;
>   		if (retry--) {
>   			msleep(20);
>   			goto retry_zapq;
> @@ -1345,13 +1395,20 @@ static int vfio_ap_mdev_reset_queue(struct vfio_ap_queue *q, unsigned int retry)
>   	case AP_RESPONSE_Q_NOT_AVAIL:
>   	case AP_RESPONSE_DECONFIGURED:
>   	case AP_RESPONSE_CHECKSTOPPED:
> -		WARN_ON_ONCE(status.irq_enabled);
> +		WARN_ONCE(status.irq_enabled,
> +			  "PQAP/ZAPQ for %02x.%04x failed with rc=%u while IRQ enabled",
> +			  AP_QID_CARD(q->apqn), AP_QID_QUEUE(q->apqn),
> +			  status.response_code);
> +		q->reset_rc = status.response_code;
>   		ret = -EBUSY;
>   		goto free_resources;
>   	default:
>   		/* things are really broken, give up */
> -		WARN(true, "PQAP/ZAPQ completed with invalid rc (%x)\n",
> +		WARN(true,
> +		     "PQAP/ZAPQ for %02x.%04x failed with invalid rc=%u\n",
> +		     AP_QID_CARD(q->apqn), AP_QID_QUEUE(q->apqn),
>   		     status.response_code);
> +		q->reset_rc = status.response_code;
>   		return -EIO;
>   	}
...

-- 
-- Jason J. Herne (jjherne@linux.ibm.com)

  reply	other threads:[~2022-03-15 14:14 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15  0:50 [PATCH v18 00/17] s390/vfio-ap: dynamic configuration support Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 01/18] s390/ap: driver callback to indicate resource in use Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 02/18] s390/ap: notify drivers on config changed and scan complete callbacks Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 03/18] s390/vfio-ap: use new AP bus interface to search for queue devices Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 04/18] s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 05/18] s390/vfio-ap: manage link between queue struct and matrix mdev Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 06/18] s390/vfio-ap: introduce shadow APCB Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 07/18] s390/vfio-ap: refresh guest's APCB by filtering APQNs assigned to mdev Tony Krowiak
2022-03-02 19:35   ` Jason J. Herne
2022-03-02 23:43     ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 08/18] s390/vfio-ap: allow assignment of unavailable AP queues to mdev device Tony Krowiak
2022-03-03 15:39   ` Jason J. Herne
2022-03-07 12:31     ` Tony Krowiak
2022-03-07 13:27       ` Halil Pasic
2022-03-07 14:10         ` Tony Krowiak
2022-03-07 17:10           ` Halil Pasic
2022-03-07 23:45             ` Tony Krowiak
2022-03-08 10:06               ` Halil Pasic
2022-03-08 15:36                 ` Tony Krowiak
2022-03-08 15:39       ` Jason J. Herne
2022-03-09  0:56         ` Halil Pasic
2022-02-15  0:50 ` [PATCH v18 09/18] s390/vfio-ap: introduce new mutex to control access to the KVM pointer Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 10/18] s390/vfio-ap: allow hot plug/unplug of AP devices when assigned/unassigned Tony Krowiak
2022-03-11 14:26   ` Jason J. Herne
2022-03-11 16:07     ` Tony Krowiak
2022-03-14 13:17       ` Jason J. Herne
2022-03-18 17:30         ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 11/18] s390/vfio-ap: hot plug/unplug of AP devices when probed/removed Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 12/18] s390/vfio-ap: reset queues after adapter/domain unassignment Tony Krowiak
2022-03-15 14:13   ` Jason J. Herne [this message]
2022-03-18 17:54     ` Tony Krowiak
2022-03-18 22:13       ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 13/18] s390/vfio-ap: implement in-use callback for vfio_ap driver Tony Krowiak
2022-03-22 13:13   ` Jason J. Herne
2022-03-22 13:30     ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 14/18] s390/vfio-ap: sysfs attribute to display the guest's matrix Tony Krowiak
2022-03-22 13:22   ` Jason J. Herne
2022-03-22 13:41     ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 15/18] s390/vfio-ap: handle config changed and scan complete notification Tony Krowiak
2022-03-24 14:09   ` Jason J. Herne
2022-03-30 19:26     ` Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 16/18] s390/vfio-ap: update docs to include dynamic config support Tony Krowiak
2022-02-15  0:50 ` [PATCH v18 17/18] s390/Docs: new doc describing lock usage by the vfio_ap device driver Tony Krowiak
2022-03-31  0:28   ` Halil Pasic
2022-04-04 21:34     ` Tony Krowiak
2022-04-06  8:23       ` Halil Pasic
2022-02-15  0:50 ` [PATCH v18 18/18] MAINTAINERS: pick up all vfio_ap docs for VFIO AP maintainers Tony Krowiak
2022-02-22 19:09 ` [PATCH v18 00/17] s390/vfio-ap: dynamic configuration support Tony Krowiak
2022-02-28 15:53 ` Tony Krowiak
2022-03-02 14:10   ` Jason J. Herne

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=6083d83b-6867-2525-fdd8-baccde1a599f@linux.ibm.com \
    --to=jjherne@linux.ibm.com \
    --cc=akrowiak@linux.ibm.com \
    --cc=alex.williamson@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=fiuczy@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=pasic@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.