From: Cornelia Huck <cohuck@redhat.com>
To: Eric Farman <farman@linux.ibm.com>
Cc: Kirti Wankhede <kwankhede@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
Halil Pasic <pasic@linux.ibm.com>,
Matthew Rosato <mjrosato@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v2 1/2] vfio-mdev: Wire in a request handler for mdev parent
Date: Tue, 24 Nov 2020 10:57:07 +0100 [thread overview]
Message-ID: <20201124105707.7f5802eb.cohuck@redhat.com> (raw)
In-Reply-To: <20201120180740.87837-2-farman@linux.ibm.com>
On Fri, 20 Nov 2020 19:07:39 +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
> device being physically removed from the host can be (gracefully?)
> handled by the parent device at the time the device is removed.
>
> Add a message when registering the device if a driver doesn't
> provide this callback, so a clue is given that this same loop
> may be encountered in a similar situation.
>
> Signed-off-by: Eric Farman <farman@linux.ibm.com>
> ---
> drivers/vfio/mdev/mdev_core.c | 4 ++++
> drivers/vfio/mdev/vfio_mdev.c | 10 ++++++++++
> include/linux/mdev.h | 4 ++++
> 3 files changed, 18 insertions(+)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
next prev parent reply other threads:[~2020-11-24 9:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-20 18:07 [PATCH v2 0/2] Connect request callback to mdev and vfio-ccw Eric Farman
2020-11-20 18:07 ` [PATCH v2 1/2] vfio-mdev: Wire in a request handler for mdev parent Eric Farman
2020-11-24 9:57 ` Cornelia Huck [this message]
2020-12-02 20:28 ` Alex Williamson
2020-12-03 3:02 ` Eric Farman
2020-11-20 18:07 ` [PATCH v2 2/2] vfio-ccw: Wire in the request callback Eric Farman
2020-11-24 10:00 ` [PATCH v2 0/2] Connect request callback to mdev and vfio-ccw 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=20201124105707.7f5802eb.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=farman@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox