search for: blk_mq_stop_hw_queues

Two patches are handling new edge cases introduced by doing DMA mappings (which can fail) in virtio core. I stumbled upon this while stress testing I/O for Protected Virtual Machines. I deliberately chose a tiny swiotlb size and have generated load with fio. With more than one virtio-blk disk in use I experienced hangs. The goal of this series is to fix those hangs. Halil Pasic (2):

Two patches are handling new edge cases introduced by doing DMA mappings (which can fail) in virtio core. I stumbled upon this while stress testing I/O for Protected Virtual Machines. I deliberately chose a tiny swiotlb size and have generated load with fio. With more than one virtio-blk disk in use I experienced hangs. The goal of this series is to fix those hangs. Halil Pasic (2):

Hi Halil, When swiotlb full is hit for virtio_blk, there is below warning for once (the warning is not by this patch set). Is this expected or just false positive? [ 54.767257] virtio-pci 0000:00:04.0: swiotlb buffer is full (sz: 16 bytes), total 32768 (slots), used 258 (slots) [ 54.767260] virtio-pci 0000:00:04.0: overflow 0x0000000075770110+16 of DMA mask ffffffffffffffff bus limit 0 [

Since nobody else is going to restart our hw_queue for us, the blk_mq_start_stopped_hw_queues() is in virtblk_done() is not sufficient necessarily sufficient to ensure that the queue will get started again. In case of global resource outage (-ENOMEM because mapping failure, because of swiotlb full) our virtqueue may be empty and we can get stuck with a stopped hw_queue. Let us not stop the queue

...ev); > > /* Prevent config work handler from accessing the device. */ dito on the comment > - mutex_lock(&vblk->config_lock); > - vblk->config_enable = false; > - mutex_unlock(&vblk->config_lock); > - > flush_work(&vblk->config_work); > > blk_mq_stop_hw_queues(vblk->disk->queue);

...ev); > > /* Prevent config work handler from accessing the device. */ dito on the comment > - mutex_lock(&vblk->config_lock); > - vblk->config_enable = false; > - mutex_unlock(&vblk->config_lock); > - > flush_work(&vblk->config_work); > > blk_mq_stop_hw_queues(vblk->disk->queue);

From: Halil Pasic <pasic at linux.ibm.com> [ Upstream commit 3d973b2e9a625996ee997c7303cd793b9d197c65 ] Let's change the mapping between virtqueue_add errors to BLK_STS statuses, so that -ENOSPC, which indicates virtqueue full is still mapped to BLK_STS_DEV_RESOURCE, but -ENOMEM which indicates non-device specific resource outage is mapped to BLK_STS_RESOURCE. Signed-off-by: Halil

From: Halil Pasic <pasic at linux.ibm.com> [ Upstream commit 3d973b2e9a625996ee997c7303cd793b9d197c65 ] Let's change the mapping between virtqueue_add errors to BLK_STS statuses, so that -ENOSPC, which indicates virtqueue full is still mapped to BLK_STS_DEV_RESOURCE, but -ENOMEM which indicates non-device specific resource outage is mapped to BLK_STS_RESOURCE. Signed-off-by: Halil

From: Halil Pasic <pasic at linux.ibm.com> [ Upstream commit 3d973b2e9a625996ee997c7303cd793b9d197c65 ] Let's change the mapping between virtqueue_add errors to BLK_STS statuses, so that -ENOSPC, which indicates virtqueue full is still mapped to BLK_STS_DEV_RESOURCE, but -ENOMEM which indicates non-device specific resource outage is mapped to BLK_STS_RESOURCE. Signed-off-by: Halil

...freeze(struct virtio_device *vdev) vdev->config->reset(vdev); /* Prevent config work handler from accessing the device. */ - mutex_lock(&vblk->config_lock); - vblk->config_enable = false; - mutex_unlock(&vblk->config_lock); - flush_work(&vblk->config_work); blk_mq_stop_hw_queues(vblk->disk->queue); @@ -823,7 +809,6 @@ static int virtblk_restore(struct virtio_device *vdev) struct virtio_blk *vblk = vdev->priv; int ret; - vblk->config_enable = true; ret = init_vq(vdev->priv); if (!ret) blk_mq_start_stopped_hw_queues(vblk->disk->queue, true);...

...; > dito on the comment Same here and in -net. Pls confirm. > > - mutex_lock(&vblk->config_lock); > > - vblk->config_enable = false; > > - mutex_unlock(&vblk->config_lock); > > - > > flush_work(&vblk->config_work); > > > > blk_mq_stop_hw_queues(vblk->disk->queue);

On Fri, Jun 20, 2014 at 11:29:40PM +0800, Ming Lei wrote: > Firstly this patch supports more than one virtual queues for virtio-blk > device. > > Secondly this patch maps the virtual queue to blk-mq's hardware queue. > > With this approach, both scalability and performance can be improved. > > Signed-off-by: Ming Lei <ming.lei at canonical.com> > --- >

On Fri, Jun 20, 2014 at 11:29:40PM +0800, Ming Lei wrote: > Firstly this patch supports more than one virtual queues for virtio-blk > device. > > Secondly this patch maps the virtual queue to blk-mq's hardware queue. > > With this approach, both scalability and performance can be improved. > > Signed-off-by: Ming Lei <ming.lei at canonical.com> > --- >

...set(vdev); - /* Prevent config work handler from accessing the device. */ - mutex_lock(&vblk->config_lock); - vblk->config_enable = false; - mutex_unlock(&vblk->config_lock); - + /* Make sure no work handler is accessing the device. */ flush_work(&vblk->config_work); blk_mq_stop_hw_queues(vblk->disk->queue); @@ -823,7 +809,6 @@ static int virtblk_restore(struct virtio_device *vdev) struct virtio_blk *vblk = vdev->priv; int ret; - vblk->config_enable = true; ret = init_vq(vdev->priv); if (!ret) blk_mq_start_stopped_hw_queues(vblk->disk->queue, true);...

Since the need for a special flag to support SCSI passthrough on a block device was added in May 2017 the SCSI passthrough support in virtio-blk has been disabled. It has always been a bad idea (just ask the original author..) and we have virtio-scsi for proper passthrough. The feature also never made it into the virtio 1.0 or later specifications. Signed-off-by: Christoph Hellwig <hch at

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

On Thu, Jun 26, 2014 at 10:08:46AM +0800, Ming Lei wrote: > Firstly this patch supports more than one virtual queues for virtio-blk > device. > > Secondly this patch maps the virtual queue to blk-mq's hardware queue. > > With this approach, both scalability and performance can be improved. > > Signed-off-by: Ming Lei <ming.lei at canonical.com> > --- >

On Thu, Jun 26, 2014 at 10:08:46AM +0800, Ming Lei wrote: > Firstly this patch supports more than one virtual queues for virtio-blk > device. > > Secondly this patch maps the virtual queue to blk-mq's hardware queue. > > With this approach, both scalability and performance can be improved. > > Signed-off-by: Ming Lei <ming.lei at canonical.com> > --- >

Firstly this patch supports more than one virtual queues for virtio-blk device. Secondly this patch maps the virtual queue to blk-mq's hardware queue. With this approach, both scalability and performance can be improved. Signed-off-by: Ming Lei <ming.lei at canonical.com> --- drivers/block/virtio_blk.c | 70 +++++++++++++++++++++++++++++++------------- 1 file changed, 50