Heinz Graalfs <[email protected]> writes:
> On 19/12/13 01:19, Rusty Russell wrote:
>> Heinz Graalfs <[email protected]> writes:
>>> On 17/12/13 04:42, Rusty Russell wrote:
>>>> Heinz Graalfs <[email protected]> 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.
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Reply via email to