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 0/2] Connect request callback to mdev and vfio-ccw
Date: Tue, 24 Nov 2020 11:00:57 +0100 [thread overview]
Message-ID: <20201124110057.78092517.cohuck@redhat.com> (raw)
In-Reply-To: <20201120180740.87837-1-farman@linux.ibm.com>
On Fri, 20 Nov 2020 19:07:38 +0100
Eric Farman <farman@linux.ibm.com> wrote:
> There is a situation where removing all the paths from a device
> connected via mdev and vfio-ccw can cause some difficulty.
> Using the "chchp -c 0 xx" command to all paths will cause the
> device to be removed from the configuration, and any guest
> filesystem that is relying on that device will encounter errors.
> Interestingly, the last chchp command will actually fail to
> return to a shell prompt, and subsequent commands (another
> chchp to bring the paths back online, chzdev, etc.) will also
> hang because of the outstanding chchp.
>
> The last chchp command drives to vfio_ccw_sch_remove() for every
> affected mediated device, and ultimately enters an infinite loop
> in vfio_del_group_dev(). This loop is broken when the guest goes
> away, which in this case doesn't occur until the guest is shutdown.
> This drives vfio_ccw_mdev_release() and thus vfio_device_release()
> to wake up the vfio_del_group_dev() thread.
>
> There is also a callback mechanism called "request" to ask a
> driver (and perhaps user) to release the device, but this is not
> implemented for mdev. So this adds one to that point, and then
> wire it to vfio-ccw to pass it along to userspace. This will
> gracefully drive the unplug code, and everything behaves nicely.
>
> Despite the testing that was occurring, this doesn't appear related
> to the vfio-ccw channel path handling code. I can reproduce this with
> an older kernel/QEMU, which makes sense because the above behavior is
> driven from the subchannel event codepaths and not the chpid events.
> Because of that, I didn't flag anything with a Fixes tag, since it's
> seemingly been this way forever.
Both patches look good to me.
Which would be the best way to merge this? Via vfio or via vfio-ccw?
>
> RFC->V2:
> - Patch 1
> - Added a message when registering a device without a request callback
> - Changed the "if(!callback) return" to "if(callback) do" layout
> - Removed "unlikely" from "if(callback)" logic
> - Clarified some wording in the device ops struct commentary
> - Patch 2
> - Added Conny's r-b
>
> Eric Farman (2):
> vfio-mdev: Wire in a request handler for mdev parent
> vfio-ccw: Wire in the request callback
>
> drivers/s390/cio/vfio_ccw_ops.c | 26 ++++++++++++++++++++++++++
> drivers/s390/cio/vfio_ccw_private.h | 4 ++++
> drivers/vfio/mdev/mdev_core.c | 4 ++++
> drivers/vfio/mdev/vfio_mdev.c | 10 ++++++++++
> include/linux/mdev.h | 4 ++++
> include/uapi/linux/vfio.h | 1 +
> 6 files changed, 49 insertions(+)
>
prev parent reply other threads:[~2020-11-24 10:01 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
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 ` Cornelia Huck [this message]
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=20201124110057.78092517.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 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.