kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@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, freude@linux.ibm.com,
	borntraeger@de.ibm.com, cohuck@redhat.com,
	mjrosato@linux.ibm.com, alex.williamson@redhat.com,
	kwankhede@nvidia.com, fiuczy@linux.ibm.com,
	frankja@linux.ibm.com, david@redhat.com, hca@linux.ibm.com,
	gor@linux.ibm.com
Subject: Re: [PATCH v11 01/14] s390/vfio-ap: No need to disable IRQ after queue reset
Date: Tue, 27 Oct 2020 07:48:46 +0100	[thread overview]
Message-ID: <20201027074846.30ee0ddc.pasic@linux.ibm.com> (raw)
In-Reply-To: <20201022171209.19494-2-akrowiak@linux.ibm.com>

On Thu, 22 Oct 2020 13:11:56 -0400
Tony Krowiak <akrowiak@linux.ibm.com> wrote:

> The queues assigned to a matrix mediated device are currently reset when:
> 
> * The VFIO_DEVICE_RESET ioctl is invoked
> * The mdev fd is closed by userspace (QEMU)
> * The mdev is removed from sysfs.

What about the situation when vfio_ap_mdev_group_notifier() is called to
tell us that our pointer to KVM is about to become invalid? Do we need to
clean up the IRQ stuff there?

> 
> Immediately after the reset of a queue, a call is made to disable
> interrupts for the queue. This is entirely unnecessary because the reset of
> a queue disables interrupts, so this will be removed.

Makes sense.

> 
> Since interrupt processing may have been enabled by the guest, it may also
> be necessary to clean up the resources used for interrupt processing. Part
> of the cleanup operation requires a reference to KVM, so a check is also
> being added to ensure the reference to KVM exists. The reason is because
> the release callback - invoked when userspace closes the mdev fd - removes
> the reference to KVM. When the remove callback - called when the mdev is
> removed from sysfs - is subsequently invoked, there will be no reference to
> KVM when the cleanup is performed.

Please see below in the code.

> 
> This patch will also do a bit of refactoring due to the fact that the
> remove callback, implemented in vfio_ap_drv.c, disables the queue after
> resetting it. Instead of the remove callback making a call into the
> vfio_ap_ops.c to clean up the resources used for interrupt processing,
> let's move the probe and remove callbacks into the vfio_ap_ops.c
> file keep all code related to managing queues in a single file.
>

It would have been helpful to split out the refactoring as a separate
patch. This way it is harder to review the code that got moved, because
it is intermingled with the changes that intend to change behavior.
 
> Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com>
> ---
>  drivers/s390/crypto/vfio_ap_drv.c     | 45 +------------------
>  drivers/s390/crypto/vfio_ap_ops.c     | 63 +++++++++++++++++++--------
>  drivers/s390/crypto/vfio_ap_private.h |  7 +--
>  3 files changed, 52 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
> index be2520cc010b..73bd073fd5d3 100644
> --- a/drivers/s390/crypto/vfio_ap_drv.c
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -43,47 +43,6 @@ static struct ap_device_id ap_queue_ids[] = {
>  
>  MODULE_DEVICE_TABLE(vfio_ap, ap_queue_ids);
>  
> -/**
> - * vfio_ap_queue_dev_probe:
> - *
> - * Allocate a vfio_ap_queue structure and associate it
> - * with the device as driver_data.
> - */
> -static int vfio_ap_queue_dev_probe(struct ap_device *apdev)
> -{
> -	struct vfio_ap_queue *q;
> -
> -	q = kzalloc(sizeof(*q), GFP_KERNEL);
> -	if (!q)
> -		return -ENOMEM;
> -	dev_set_drvdata(&apdev->device, q);
> -	q->apqn = to_ap_queue(&apdev->device)->qid;
> -	q->saved_isc = VFIO_AP_ISC_INVALID;
> -	return 0;
> -}
> -
> -/**
> - * vfio_ap_queue_dev_remove:
> - *
> - * Takes the matrix lock to avoid actions on this device while removing
> - * Free the associated vfio_ap_queue structure
> - */
> -static void vfio_ap_queue_dev_remove(struct ap_device *apdev)
> -{
> -	struct vfio_ap_queue *q;
> -	int apid, apqi;
> -
> -	mutex_lock(&matrix_dev->lock);
> -	q = dev_get_drvdata(&apdev->device);
> -	dev_set_drvdata(&apdev->device, NULL);
> -	apid = AP_QID_CARD(q->apqn);
> -	apqi = AP_QID_QUEUE(q->apqn);
> -	vfio_ap_mdev_reset_queue(apid, apqi, 1);
> -	vfio_ap_irq_disable(q);
> -	kfree(q);
> -	mutex_unlock(&matrix_dev->lock);
> -}
> -
>  static void vfio_ap_matrix_dev_release(struct device *dev)
>  {
>  	struct ap_matrix_dev *matrix_dev = dev_get_drvdata(dev);
> @@ -186,8 +145,8 @@ static int __init vfio_ap_init(void)
>  		return ret;
>  
>  	memset(&vfio_ap_drv, 0, sizeof(vfio_ap_drv));
> -	vfio_ap_drv.probe = vfio_ap_queue_dev_probe;
> -	vfio_ap_drv.remove = vfio_ap_queue_dev_remove;
> +	vfio_ap_drv.probe = vfio_ap_mdev_probe_queue;
> +	vfio_ap_drv.remove = vfio_ap_mdev_remove_queue;
>  	vfio_ap_drv.ids = ap_queue_ids;
>  
>  	ret = ap_driver_register(&vfio_ap_drv, THIS_MODULE, VFIO_AP_DRV_NAME);
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
> index e0bde8518745..c471832f0a30 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -119,7 +119,8 @@ static void vfio_ap_wait_for_irqclear(int apqn)
>   */
>  static void vfio_ap_free_aqic_resources(struct vfio_ap_queue *q)
>  {
> -	if (q->saved_isc != VFIO_AP_ISC_INVALID && q->matrix_mdev)
> +	if (q->saved_isc != VFIO_AP_ISC_INVALID && q->matrix_mdev &&
> +	    q->matrix_mdev->kvm)

Here is the check that the kvm reference exists, you mentioned in the
cover letter. You make only the gisc_unregister depend on it, because
that's what is going to explode.

But I'm actually wondering if "KVM is gone but we still haven't cleaned
up our aqic resources" is valid. I argue that it is not. The two
resources we manage are the gisc registration and the pinned page. I
argue that it makes on sense to keep what was the guests page pinned,
if here is no guest associated (we don't have KVM).

I assume the cleanup is supposed to be atomic from the perspective of
other threads/contexts, so I expect the cleanup either to be fully done
or not not entered the critical section.

So !kvm && (q->saved_isc != VFIO_AP_ISC_INVALID || q->saved_pfn) is a
bug. Isn't it?

In that sense this change would only hide the actual problem.

Is the scenario we are talking about something that can happen, or is
this just about programming defensively?

In any case, I don't think this is a good idea. We can be defensive
about it, but we have to do it differently.


>  		kvm_s390_gisc_unregister(q->matrix_mdev->kvm, q->saved_isc);
>  	if (q->saved_pfn && q->matrix_mdev)
>  		vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
> @@ -144,7 +145,7 @@ static void vfio_ap_free_aqic_resources(struct vfio_ap_queue *q)
>   * Returns if ap_aqic function failed with invalid, deconfigured or
>   * checkstopped AP.
>   */
> -struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
> +static struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
>  {
>  	struct ap_qirq_ctrl aqic_gisa = {};
>  	struct ap_queue_status status;
> @@ -297,6 +298,7 @@ static int handle_pqap(struct kvm_vcpu *vcpu)
>  	if (!q)
>  		goto out_unlock;
>  
> +	q->matrix_mdev = matrix_mdev;

What is the purpose of this? Doesn't the preceding vfio_ap_get_queue()
already set q->matrix_mdev?

>  	status = vcpu->run->s.regs.gprs[1];
>  
>  	/* If IR bit(16) is set we enable the interrupt */
> @@ -1114,20 +1116,6 @@ static int vfio_ap_mdev_group_notifier(struct notifier_block *nb,
>  	return NOTIFY_OK;
>  }
>  
> -static void vfio_ap_irq_disable_apqn(int apqn)
> -{
> -	struct device *dev;
> -	struct vfio_ap_queue *q;
> -
> -	dev = driver_find_device(&matrix_dev->vfio_ap_drv->driver, NULL,
> -				 &apqn, match_apqn);
> -	if (dev) {
> -		q = dev_get_drvdata(dev);
> -		vfio_ap_irq_disable(q);
> -		put_device(dev);
> -	}
> -}
> -
>  int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
>  			     unsigned int retry)
>  {
> @@ -1162,6 +1150,7 @@ static int vfio_ap_mdev_reset_queues(struct mdev_device *mdev)
>  {
>  	int ret;
>  	int rc = 0;
> +	struct vfio_ap_queue *q;
>  	unsigned long apid, apqi;
>  	struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
>  
> @@ -1177,7 +1166,10 @@ static int vfio_ap_mdev_reset_queues(struct mdev_device *mdev)
>  			 */
>  			if (ret)
>  				rc = ret;
> -			vfio_ap_irq_disable_apqn(AP_MKQID(apid, apqi));
> +			q = vfio_ap_get_queue(matrix_mdev,
> +					      AP_MKQID(apid, apqi));
> +			if (q)
> +				vfio_ap_free_aqic_resources(q);

Is it safe to do vfio_ap_free_aqic_resources() at this point? I don't
think so. I mean does the current code (and vfio_ap_mdev_reset_queue()
in particular guarantee that the reset is actually done when we arrive
here)? BTW, I think we have a similar problem with the current code as
well.

Under what circumstances do we expect !q? If we don't, then we need to
complain one way or another.

I believe that each time we call vfio_ap_mdev_reset_queue(), we will
also want to call vfio_ap_free_aqic_resources(q) to clean up our aqic
resources associated with the queue -- if any. So I would really prefer
having a function that does both.

>  		}
>  	}
>  
> @@ -1302,3 +1294,40 @@ void vfio_ap_mdev_unregister(void)
>  {
>  	mdev_unregister_device(&matrix_dev->device);
>  }
> +
> +int vfio_ap_mdev_probe_queue(struct ap_device *apdev)
> +{
> +	struct vfio_ap_queue *q;
> +	struct ap_queue *queue;
> +
> +	queue = to_ap_queue(&apdev->device);
> +
> +	q = kzalloc(sizeof(*q), GFP_KERNEL);
> +	if (!q)
> +		return -ENOMEM;
> +
> +	dev_set_drvdata(&queue->ap_dev.device, q);
> +	q->apqn = queue->qid;
> +	q->saved_isc = VFIO_AP_ISC_INVALID;
> +
> +	return 0;
> +}
> +
> +void vfio_ap_mdev_remove_queue(struct ap_device *apdev)
> +{
> +	struct vfio_ap_queue *q;
> +	struct ap_queue *queue;
> +	int apid, apqi;
> +
> +	queue = to_ap_queue(&apdev->device);

What is the benefit of rewriting this? You introduced
queue just to do queue->ap_dev to get to the apdev you
have in hand in the first place.

> +
> +	mutex_lock(&matrix_dev->lock);
> +	q = dev_get_drvdata(&queue->ap_dev.device);
> +	dev_set_drvdata(&queue->ap_dev.device, NULL);
> +	apid = AP_QID_CARD(q->apqn);
> +	apqi = AP_QID_QUEUE(q->apqn);
> +	vfio_ap_mdev_reset_queue(apid, apqi, 1);
> +	vfio_ap_free_aqic_resources(q);
> +	kfree(q);
> +	mutex_unlock(&matrix_dev->lock);
> +}
> diff --git a/drivers/s390/crypto/vfio_ap_private.h b/drivers/s390/crypto/vfio_ap_private.h
> index f46dde56b464..d9003de4fbad 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -90,8 +90,6 @@ struct ap_matrix_mdev {
>  
>  extern int vfio_ap_mdev_register(void);
>  extern void vfio_ap_mdev_unregister(void);
> -int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
> -			     unsigned int retry);
>  
>  struct vfio_ap_queue {
>  	struct ap_matrix_mdev *matrix_mdev;
> @@ -100,5 +98,8 @@ struct vfio_ap_queue {
>  #define VFIO_AP_ISC_INVALID 0xff
>  	unsigned char saved_isc;
>  };
> -struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q);
> +
> +int vfio_ap_mdev_probe_queue(struct ap_device *queue);
> +void vfio_ap_mdev_remove_queue(struct ap_device *queue);
> +
>  #endif /* _VFIO_AP_PRIVATE_H_ */


  parent reply	other threads:[~2020-10-27  6:49 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-22 17:11 [PATCH v11 00/14] s390/vfio-ap: dynamic configuration support Tony Krowiak
2020-10-22 17:11 ` [PATCH v11 01/14] s390/vfio-ap: No need to disable IRQ after queue reset Tony Krowiak
2020-10-22 19:44   ` kernel test robot
2020-10-26 16:57     ` Tony Krowiak
2020-10-27  6:48   ` Halil Pasic [this message]
2020-10-29 23:29     ` Tony Krowiak
2020-10-30 16:13       ` Tony Krowiak
2020-10-30 17:27       ` Halil Pasic
2020-10-30 20:45         ` Tony Krowiak
2020-10-30 17:42       ` Halil Pasic
2020-10-30 20:37         ` Tony Krowiak
2020-10-31  3:43           ` Halil Pasic
2020-11-02 14:35             ` Tony Krowiak
2020-10-30 17:54       ` Halil Pasic
2020-10-30 20:53         ` Tony Krowiak
2020-10-30 21:13           ` Tony Krowiak
2020-10-30 17:56       ` Halil Pasic
2020-10-30 21:17         ` Tony Krowiak
2020-10-22 17:11 ` [PATCH v11 02/14] 390/vfio-ap: use new AP bus interface to search for queue devices Tony Krowiak
2020-10-27  7:01   ` Halil Pasic
2020-11-02 21:57     ` Tony Krowiak
2020-10-22 17:11 ` [PATCH v11 03/14] s390/vfio-ap: manage link between queue struct and matrix mdev Tony Krowiak
2020-10-27  9:33   ` Halil Pasic
2020-10-22 17:11 ` [PATCH v11 04/14] s390/zcrypt: driver callback to indicate resource in use Tony Krowiak
2020-10-27 13:01   ` Halil Pasic
2020-10-27 16:55   ` Harald Freudenberger
2020-11-13 21:30     ` Tony Krowiak
2020-11-14  0:00       ` Halil Pasic
2020-11-16 16:23         ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 05/14] s390/vfio-ap: implement in-use callback for vfio_ap driver Tony Krowiak
2020-10-27 13:27   ` Halil Pasic
2020-11-13 17:14     ` Tony Krowiak
2020-11-13 23:47       ` Halil Pasic
2020-11-16 16:58         ` Tony Krowiak
2020-11-23 17:03         ` Cornelia Huck
2020-11-23 19:23           ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 06/14] s390/vfio-ap: introduce shadow APCB Tony Krowiak
2020-10-28  8:11   ` Halil Pasic
2020-11-13 17:18     ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 07/14] s390/vfio-ap: sysfs attribute to display the guest's matrix Tony Krowiak
2020-10-28  8:17   ` Halil Pasic
2020-11-13 17:27     ` Tony Krowiak
2020-11-13 23:12       ` Halil Pasic
2020-11-19 18:15         ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 08/14] s390/vfio-ap: hot plug/unplug queues on bind/unbind of queue device Tony Krowiak
2020-10-22 20:30   ` kernel test robot
2020-10-26 17:04     ` Tony Krowiak
2020-10-28 13:57   ` Halil Pasic
2020-11-03 22:49     ` Tony Krowiak
2020-11-04 12:52       ` Halil Pasic
2020-11-04 21:20         ` Tony Krowiak
2020-11-05 12:27           ` Halil Pasic
2020-11-13 20:36             ` Tony Krowiak
2020-11-04 13:23       ` Halil Pasic
2020-10-22 17:12 ` [PATCH v11 09/14] s390/vfio-ap: allow assignment of unavailable AP queues to mdev device Tony Krowiak
2020-10-28 15:03   ` Halil Pasic
2020-10-22 17:12 ` [PATCH v11 10/14] s390/vfio-ap: allow hot plug/unplug of AP resources using " Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 11/14] s390/zcrypt: Notify driver on config changed and scan complete callbacks Tony Krowiak
2020-10-27 17:28   ` Harald Freudenberger
2020-11-13 20:58     ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 12/14] s390/vfio-ap: handle host AP config change notification Tony Krowiak
2020-10-22 21:17   ` kernel test robot
2020-10-26 17:07     ` Tony Krowiak
2020-10-26 17:21     ` Tony Krowiak
2020-11-03  9:48   ` kernel test robot
2020-11-13 21:06     ` Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 13/14] s390/vfio-ap: handle AP bus scan completed notification Tony Krowiak
2020-10-22 17:12 ` [PATCH v11 14/14] s390/vfio-ap: update docs to include dynamic config support 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=20201027074846.30ee0ddc.pasic@linux.ibm.com \
    --to=pasic@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=fiuczy@linux.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@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 \
    /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;
as well as URLs for NNTP newsgroup(s).