From: Heinz Graalfs <graalfs@linux.vnet.ibm.com>
To: mst@redhat.com, virtualization@lists.linux-foundation.org
Cc: borntraeger@de.ibm.com
Subject: [PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
Date: Fri, 13 Dec 2013 14:13:27 +0100 [thread overview]
Message-ID: <1386940410-44943-1-git-send-email-graalfs@linux.vnet.ibm.com> (raw)
Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th.
When an active virtio block device is hot-unplugged from a KVM guest,
affected guest user applications are not aware of any errors that occur
due to the lost device. This patch-set adds code to avoid further request
queueing when a lost block device is detected, resulting in appropriate
error info. Additionally a potential hang situation can be avoided by not
waiting for requests (e.g. in-flight requests) in blk_cleanup_queue() that
will never complete.
On System z there exists no handshake mechanism between host and guest
when a device is hot-unplugged. The device is removed and no further I/O
is possible.
When an online channel device disappears on System z the kernel's CIO layer
informs the driver (virtio_ccw) about the lost device.
Here are some more error details:
For a particular block device virtio's request function virtblk_request()
is called by the block layer to queue requests to be handled by the host.
In case of a lost device requests can still be queued, but an appropriate
subsequent host kick usually fails. This leads to situations where no error
feedback is shown.
In order to prevent request queueing for lost devices appropriate settings
in the block layer should be made. Exploiting System z's CIO notify handler
callback, and passing on device loss information via the surprize_removal
flag to the remove callback of the backend driver, can solve this task.
v3->v4 changes:
- patch 1: solves some vcdev pointer handling issues in the virtio_ccw driver
(e.g. locked vcdev pointer reset/query; serialize remove()/set_offline()
callback processing).
- patch 2: introduces 'device_lost' atomic in virtio_device and use in
backend driver virtio_blk accordingly (original 3 patches merged).
- patch 3: the notify() callback is now serialized with remove()/set_offline()
callbacks. The notification is ignored if the vcdev pointer has been cleared
already (by remove() or set_offline()).
v2->v3 changes:
- remove virtio_driver's notify callback (and appropriate code) introduced
in my v1 RFC
- introduce 'surprize_removal' in struct virtio_device
- change virtio_blk's remove callback to perform special actions when the
surprize_removal flag is set
- avoid final I/O by preventing further request queueing
- avoid hangs in blk_cleanup_queue() due to waits on 'in-flight' requests
- set surprize_removal in virtio_ccw's notify callback when a device is lost
v1->v2 changes:
- add include of linux/notifier.h (I also added it to the 3rd patch)
- get queue lock in order to be able to use safe queue_flag_set() functions
in virtblk_notify() handler
Heinz Graalfs (3):
virtio_ccw: fix vcdev pointer handling issues
virtio: introduce 'device_lost' flag in virtio_device
virtio_ccw: set 'device_lost' on CIO_GONE notification
drivers/block/virtio_blk.c | 14 ++++++++++-
drivers/s390/kvm/virtio_ccw.c | 58 ++++++++++++++++++++++++++++++++++++-------
include/linux/virtio.h | 2 ++
3 files changed, 64 insertions(+), 10 deletions(-)
--
1.8.3.1
next reply other threads:[~2013-12-13 13:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 13:13 Heinz Graalfs [this message]
2013-12-13 13:13 ` [PATCH v4 RFC 1/3] virtio_ccw: fix vcdev pointer handling issues Heinz Graalfs
2013-12-13 13:13 ` [PATCH v4 RFC 2/3] virtio: introduce 'device_lost' flag in virtio_device Heinz Graalfs
2013-12-13 13:13 ` [PATCH v4 RFC 3/3] virtio_ccw: set 'device_lost' on CIO_GONE notification Heinz Graalfs
2013-12-17 3:42 ` [PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device Rusty Russell
2013-12-17 14:01 ` Heinz Graalfs
2013-12-19 0:19 ` Rusty Russell
2013-12-23 8:39 ` Heinz Graalfs
2014-01-13 12:12 ` Fwd: " Heinz Graalfs
2014-01-15 2:18 ` Rusty Russell
2014-01-23 4:51 ` Rusty Russell
2014-01-28 16:12 ` Heinz Graalfs
2014-01-29 6:31 ` Rusty Russell
2014-02-18 10:58 ` Heinz Graalfs
2014-02-20 8:03 ` Rusty Russell
2014-02-20 15:39 ` Heinz Graalfs
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=1386940410-44943-1-git-send-email-graalfs@linux.vnet.ibm.com \
--to=graalfs@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=mst@redhat.com \
--cc=virtualization@lists.linux-foundation.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;
as well as URLs for NNTP newsgroup(s).