From: Rusty Russell <rusty@rustcorp.com.au>
To: Heinz Graalfs <graalfs@linux.vnet.ibm.com>,
mst@redhat.com, virtualization@lists.linux-foundation.org
Cc: borntraeger@de.ibm.com
Subject: Re: [PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
Date: Wed, 15 Jan 2014 12:48:42 +1030 [thread overview]
Message-ID: <874n56xa0t.fsf@rustcorp.com.au> (raw)
In-Reply-To: <52B7F6B1.9070300@linux.vnet.ibm.com>
Heinz Graalfs <graalfs@linux.vnet.ibm.com> writes:
> On 19/12/13 01:19, Rusty Russell wrote:
>> Heinz Graalfs <graalfs@linux.vnet.ibm.com> writes:
>>> On 17/12/13 04:42, Rusty Russell wrote:
>>>> Heinz Graalfs <graalfs@linux.vnet.ibm.com> writes:
>>>>> 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.
>>>>
>>>>
>>>> Hi Heinz,
>>>>
>>>> If you simply mark every virtqueue as broken when this
>>>> unexpected unplug happens, does that not Just Work?
>>>>
>>>> I think I've asked this before...
>>>> Rusty.
>>>
>>> Hi Rusty,
>>>
>>> setting the (one) virtqueue, vblk is currently using, as broken doesn't
>>> solve the problems.
>>>
>>> In that case virtblk_request()s still succeed - like this one...
>>
>> No, you set *all* virtqueues broken. Which is accurate, right?
>>
>> Cheers,
>> Rusty.
>>
>
> I'm sorry, but I don't get this.
> The vblk involved has only 1 virtqueue.
> What do you mean by all "*all* virtqueues ?
Sorry, that was my mistake. I was referring to the general problem,
and didn't read your previous response.
OK, firstly virtqueue_add *should* fail if vq is broken. Then it would
work, right? ie. Our drivers should already handle the case where a
virtqueue is marked broken, right? Otherwise they're not robust.
Patch queue coming...
Thanks,
Rusty.
next prev parent reply other threads:[~2014-01-15 2:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 13:13 [PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device Heinz Graalfs
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 [this message]
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=874n56xa0t.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=borntraeger@de.ibm.com \
--cc=graalfs@linux.vnet.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 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.