Heinz Graalfs <graalfs@xxxxxxxxxxxxxxxxxx> writes: > On 19/12/13 01:19, Rusty Russell wrote: >> Heinz Graalfs <graalfs@xxxxxxxxxxxxxxxxxx> writes: >>> On 17/12/13 04:42, Rusty Russell wrote: >>>> Heinz Graalfs <graalfs@xxxxxxxxxxxxxxxxxx> 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 Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
