From: Halil Pasic <pasic@linux.ibm.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
Kirti Wankhede <kwankhede@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] vfio-mdev: Wire in a request handler for mdev parent
Date: Thu, 19 Nov 2020 16:29:58 +0100 [thread overview]
Message-ID: <20201119162958.2c1a0781.pasic@linux.ibm.com> (raw)
In-Reply-To: <20201117032139.50988-2-farman@linux.ibm.com>
On Tue, 17 Nov 2020 04:21:38 +0100
Eric Farman <farman@linux.ibm.com> wrote:
> While performing some destructive tests with vfio-ccw, where the
> paths to a device are forcible removed and thus the device itself
> is unreachable, it is rather easy to end up in an endless loop in
> vfio_del_group_dev() due to the lack of a request callback for the
> associated device.
>
> In this example, one MDEV (77c) is used by a guest, while another
> (77b) is not. The symptom is that the iommu is detached from the
> mdev for 77b, but not 77c, until that guest is shutdown:
>
> [ 238.794867] vfio_ccw 0.0.077b: MDEV: Unregistering
> [ 238.794996] vfio_mdev 11f2d2bc-4083-431d-a023-eff72715c4f0: Removing from iommu group 2
> [ 238.795001] vfio_mdev 11f2d2bc-4083-431d-a023-eff72715c4f0: MDEV: detaching iommu
> [ 238.795036] vfio_ccw 0.0.077c: MDEV: Unregistering
> ...silence...
>
> Let's wire in the request call back to the mdev device, so that a hot
> unplug can be (gracefully?) handled by the parent device at the time
> the device is being removed.
>
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
> drivers/vfio/mdev/vfio_mdev.c | 11 +++++++++++
> include/linux/mdev.h | 4 ++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
> index 30964a4e0a28..2dd243f73945 100644
> --- a/drivers/vfio/mdev/vfio_mdev.c
> +++ b/drivers/vfio/mdev/vfio_mdev.c
> @@ -98,6 +98,16 @@ static int vfio_mdev_mmap(void *device_data, struct vm_area_struct *vma)
> return parent->ops->mmap(mdev, vma);
> }
>
> +static void vfio_mdev_request(void *device_data, unsigned int count)
> +{
> + struct mdev_device *mdev = device_data;
> + struct mdev_parent *parent = mdev->parent;
> +
> + if (unlikely(!parent->ops->request))
> + return;
> + parent->ops->request(mdev, count);
> +}
> +
> static const struct vfio_device_ops vfio_mdev_dev_ops = {
> .name = "vfio-mdev",
> .open = vfio_mdev_open,
> @@ -106,6 +116,7 @@ static const struct vfio_device_ops vfio_mdev_dev_ops = {
> .read = vfio_mdev_read,
> .write = vfio_mdev_write,
> .mmap = vfio_mdev_mmap,
> + .request = vfio_mdev_request,
> };
>
> static int vfio_mdev_probe(struct device *dev)
> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> index 0ce30ca78db0..0ed88be1f4bb 100644
> --- a/include/linux/mdev.h
> +++ b/include/linux/mdev.h
> @@ -72,6 +72,9 @@ struct device *mdev_get_iommu_device(struct device *dev);
> * @mmap: mmap callback
> * @mdev: mediated device structure
> * @vma: vma structure
> + * @request: request callback
In include/linux/vfio.h it is documented like
* @request: Request for the bus driver to release the device
Can we add 'to release' here as well?
IMHO, when one requests, one needs to say what is requested. So
I would expect a function called request() to have a parameter
(direct or indirect) that expresses, what is requested. But this
does not seem to be the case here. Or did I miss it?
Well it's called request() and not request_removal() in vfio,
so I believe it's only consistent to keep calling it request().
But I do think we should at least document what is actually requested.
Otherwise LGTM!
> + * @mdev: mediated device structure
> + * @count: request sequence number
> * Parent device that support mediated device should be registered with mdev
> * module with mdev_parent_ops structure.
> **/
> @@ -92,6 +95,7 @@ struct mdev_parent_ops {
> long (*ioctl)(struct mdev_device *mdev, unsigned int cmd,
> unsigned long arg);
> int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma);
> + void (*request)(struct mdev_device *mdev, unsigned int count);
> };
>
> /* interface for exporting mdev supported type attributes */
next prev parent reply other threads:[~2020-11-19 15:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-17 3:21 [RFC PATCH 0/2] Connect request callback to mdev and vfio-ccw Eric Farman
2020-11-17 3:21 ` [RFC PATCH 1/2] vfio-mdev: Wire in a request handler for mdev parent Eric Farman
2020-11-19 11:30 ` Cornelia Huck
2020-11-19 14:36 ` Eric Farman
2020-11-19 15:56 ` Halil Pasic
2020-11-20 11:17 ` Cornelia Huck
2020-11-23 19:12 ` Tony Krowiak
2020-11-19 16:27 ` Alex Williamson
2020-11-19 20:04 ` Eric Farman
2020-11-20 11:22 ` Cornelia Huck
2020-11-19 15:29 ` Halil Pasic [this message]
2020-11-17 3:21 ` [RFC PATCH 2/2] vfio-ccw: Wire in the request callback Eric Farman
2020-11-19 11:43 ` Cornelia Huck
2020-11-19 12:00 ` Cornelia Huck
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=20201119162958.2c1a0781.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=cohuck@redhat.com \
--cc=farman@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-s390@vger.kernel.org \
/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