search for: surprize_removal

Hi, here is an updated patch-set to my v2 RFC virtio: add new notify() callback to virtio_driver This RFC introduces a new virtio_device entry 'surprize_removal' instead of a new 'notify' callback in struct virtio_driver. 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...

Hi, here is an updated patch-set to my v2 RFC virtio: add new notify() callback to virtio_driver This RFC introduces a new virtio_device entry 'surprize_removal' instead of a new 'notify' callback in struct virtio_driver. 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...

On Wed, Nov 27, 2013 at 11:32:39AM +0100, Heinz Graalfs wrote: > Code is added to avoid calling blk_cleanup_queue() when the surprize_removal > flag is set due to a disappeared device. It avoid hangs due to incomplete > requests (e.g. in-flight requests). Such requests must be considered as lost. Ugh. Can't we complete these immediately using detach_unused_buf? If not why? > If the current remove callback was triggered due...

On Wed, Nov 27, 2013 at 11:32:39AM +0100, Heinz Graalfs wrote: > Code is added to avoid calling blk_cleanup_queue() when the surprize_removal > flag is set due to a disappeared device. It avoid hangs due to incomplete > requests (e.g. in-flight requests). Such requests must be considered as lost. Ugh. Can't we complete these immediately using detach_unused_buf? If not why? > If the current remove callback was triggered due...

Code is added to the notify handler to set the 'surprize_removal' flag in virtio_device in case a CIO_GONE notification occurs. The remove callback of the backend driver must check this flag in order to perform special processing for a lost device. Signed-off-by: Heinz Graalfs <graalfs at linux.vnet.ibm.com> --- drivers/s390/kvm/virtio_ccw.c | 16 +++...

...nt 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 '...

...nt 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 '...

...tuations 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() >&g...

...tuations 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() >&g...

...tuations 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() >&g...

...tuations 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() >&g...

On Wed, Nov 27, 2013 at 12:37:02PM +0100, Heinz Graalfs wrote: > On 27/11/13 11:47, Michael S. Tsirkin wrote: > >On Wed, Nov 27, 2013 at 11:32:39AM +0100, Heinz Graalfs wrote: > >>Code is added to avoid calling blk_cleanup_queue() when the surprize_removal > >>flag is set due to a disappeared device. It avoid hangs due to incomplete > >>requests (e.g. in-flight requests). Such requests must be considered as lost. > > > >Ugh. Can't we complete these immediately using detach_unused_buf? If not why? > > OK, I wil...

On Wed, Nov 27, 2013 at 12:37:02PM +0100, Heinz Graalfs wrote: > On 27/11/13 11:47, Michael S. Tsirkin wrote: > >On Wed, Nov 27, 2013 at 11:32:39AM +0100, Heinz Graalfs wrote: > >>Code is added to avoid calling blk_cleanup_queue() when the surprize_removal > >>flag is set due to a disappeared device. It avoid hangs due to incomplete > >>requests (e.g. in-flight requests). Such requests must be considered as lost. > > > >Ugh. Can't we complete these immediately using detach_unused_buf? If not why? > > OK, I wil...

...ls. 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)...

...ls. 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)...

...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/quer...

...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/quer...

...ror >>> 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()/...

Code is added to avoid calling blk_cleanup_queue() when the surprize_removal flag is set due to a disappeared device. It avoid hangs due to incomplete requests (e.g. in-flight requests). Such requests must be considered as lost. If the current remove callback was triggered due to an unregister driver, and the surprize_removal is not already set (although the actual device...

On 27/11/13 11:47, Michael S. Tsirkin wrote: > On Wed, Nov 27, 2013 at 11:32:39AM +0100, Heinz Graalfs wrote: >> Code is added to avoid calling blk_cleanup_queue() when the surprize_removal >> flag is set due to a disappeared device. It avoid hangs due to incomplete >> requests (e.g. in-flight requests). Such requests must be considered as lost. > > Ugh. Can't we complete these immediately using detach_unused_buf? If not why? OK, I will try > >> If the...