All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harald Freudenberger <freude@linux.ibm.com>
To: Tony Krowiak <akrowiak@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, jjherne@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 2/7] s390/vfio_ap: check TAPQ response code when waiting for queue reset
Date: Thu, 15 Dec 2022 11:48:46 +0100	[thread overview]
Message-ID: <0e7badff0648ec2b731ae7703ed5ba91@linux.ibm.com> (raw)
In-Reply-To: <20221213154437.15480-3-akrowiak@linux.ibm.com>

On 2022-12-13 16:44, Tony Krowiak wrote:
> The vfio_ap_mdev_reset_queue() function does not check the status
> response code returned form the PQAP(TAPQ) function when verifying the
> queue's status; consequently, there is no way of knowing whether
> verification failed because the wait time was exceeded, or because the
> PQAP(TAPQ) failed.
> 
> This patch adds a function to check the status response code from the
> PQAP(TAPQ) instruction and logs an appropriate message if it fails.
> 
> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
> ---
>  drivers/s390/crypto/vfio_ap_ops.c | 36 ++++++++++++++++++++++++++-----
>  1 file changed, 31 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index 83ff94a38102..a5530a46cf31 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -1587,23 +1587,49 @@ static struct vfio_ap_queue
> *vfio_ap_find_queue(int apqn)
>  	return q;
>  }
> 
> +static int apq_status_check(int apqn, struct ap_queue_status *status)
> +{
> +	switch (status->response_code) {
> +	case AP_RESPONSE_NORMAL:
> +	case AP_RESPONSE_RESET_IN_PROGRESS:
> +		if (status->queue_empty && !status->irq_enabled)
> +			return 0;
> +		return -EBUSY;
> +	case AP_RESPONSE_DECONFIGURED:
> +		/*
> +		 * If the AP queue is deconfigured, any subsequent AP command
> +		 * targeting the queue will fail with the same response code. On the
> +		 * other hand, when an AP adapter is deconfigured, the associated
> +		 * queues are reset, so let's return a value indicating the reset
> +		 * for which we're waiting completed successfully.
> +		 */
> +		return 0;
> +	default:
> +		WARN(true,
> +		     "failed to verify reset of queue %02x.%04x: TAPQ rc=%u\n",
> +		     AP_QID_CARD(apqn), AP_QID_QUEUE(apqn),
> +		     status->response_code);
> +		return -EIO;
> +	}
> +}
> +
>  static int apq_reset_check(struct vfio_ap_queue *q)
>  {
> -	int iters = 2;
> +	int iters = 2, ret;
>  	struct ap_queue_status status;
> 
>  	while (iters--) {
>  		msleep(20);
>  		status = ap_tapq(q->apqn, NULL);
> -		if (status.queue_empty && !status.irq_enabled)
> -			return 0;
> +		ret = apq_status_check(q->apqn, &status);
> +		if (ret != -EBUSY)
> +			return ret;
>  	}
>  	WARN_ONCE(iters <= 0,
>  		  "timeout verifying reset of queue %02x.%04x (%u, %u, %u)",
>  		  AP_QID_CARD(q->apqn), AP_QID_QUEUE(q->apqn),
>  		  status.queue_empty, status.irq_enabled, status.response_code);
> -
> -	return -EBUSY;
> +	return ret;
>  }
> 
>  static int vfio_ap_mdev_reset_queue(struct vfio_ap_queue *q,

Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>

Just one word here: this function is only called once and it is very 
very special
to just check the status after RAPQ/ZAPQ. I would merge this function 
into the
calling code or rename the function to reflect the special condition 
under which
it is called. However - this is not my code and I don't need to maintain 
it, so
maybe simple ignore my words.

  reply	other threads:[~2022-12-15 10:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-13 15:44 [PATCH 0/7] improve AP queue reset processing Tony Krowiak
2022-12-13 15:44 ` [PATCH 1/7] s390/vfio-ap: verify reset complete in separate function Tony Krowiak
2022-12-15  8:24   ` Harald Freudenberger
2022-12-13 15:44 ` [PATCH 2/7] s390/vfio_ap: check TAPQ response code when waiting for queue reset Tony Krowiak
2022-12-15 10:48   ` Harald Freudenberger [this message]
2022-12-13 15:44 ` [PATCH 3/7] s390/vfio_ap: use TAPQ to verify reset in progress completes Tony Krowiak
2022-12-15 10:51   ` Harald Freudenberger
2022-12-20 14:22     ` Anthony Krowiak
2022-12-13 15:44 ` [PATCH 4/7] s390/vfio_ap: verify ZAPQ completion after return of response code zero Tony Krowiak
2022-12-15 10:54   ` Harald Freudenberger
2022-12-20 14:24     ` Anthony Krowiak
2022-12-13 15:44 ` [PATCH 5/7] s390/vfio_ap: fix handling of error response codes Tony Krowiak
2022-12-15 10:56   ` Harald Freudenberger
2022-12-20 14:25     ` Anthony Krowiak
2022-12-13 15:44 ` [PATCH 6/7] s390/vfio_ap: increase max wait time for reset verification Tony Krowiak
2022-12-15 10:58   ` Harald Freudenberger
2022-12-20 14:27     ` Anthony Krowiak
2022-12-13 15:44 ` [PATCH 7/7] s390/vfio_ap: always clean up IRQ resources Tony Krowiak
2022-12-15 10:58   ` Harald Freudenberger
2022-12-19 14:10   ` Halil Pasic
2022-12-20 14:33     ` Anthony Krowiak
2022-12-20 17:24       ` Halil Pasic
2023-01-09 19:40         ` Anthony Krowiak
2022-12-14 15:16 ` [PATCH 0/7] improve AP queue reset processing Jason J. Herne
2022-12-14 19:10   ` Anthony 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=0e7badff0648ec2b731ae7703ed5ba91@linux.ibm.com \
    --to=freude@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=jjherne@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.