similar to: make SCSI passthrough support optional

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

Without this fix attempts to do scsi passthrough on virtio_blk will crash the system on virtually mapped stacks, which is something happening during boot with many distros.

Without this fix attempts to do scsi passthrough on virtio_blk will crash the system on virtually mapped stacks, which is something happening during boot with many distros.

OK, this is (ab)uses some of Paolo's patches. The first 7 are candidates for this merge window (maybe), the rest I'm not so sure about. Thanks, Rusty. Paolo Bonzini (3): scatterlist: introduce sg_unmark_end virtio-blk: reorganize virtblk_add_req virtio-blk: use virtqueue_add_sgs on req path Rusty Russell (13): virtio_ring: virtqueue_add_sgs, to add multiple sgs. virtio-blk:

OK, this is (ab)uses some of Paolo's patches. The first 7 are candidates for this merge window (maybe), the rest I'm not so sure about. Thanks, Rusty. Paolo Bonzini (3): scatterlist: introduce sg_unmark_end virtio-blk: reorganize virtblk_add_req virtio-blk: use virtqueue_add_sgs on req path Rusty Russell (13): virtio_ring: virtqueue_add_sgs, to add multiple sgs. virtio-blk:

Currently virtio-blk driver does not provide discard feature flag, so the filesystems which built on top of the block device will not send discard command. This is okay for HDD backend, but it will impact the performance for SSD backend. Add a feature flag VIRTIO_BLK_F_DISCARD and command VIRTIO_BLK_T_DISCARD to extend exist virtio-blk protocol. virtio-blk protocol uses a single 8 bytes

Currently virtio-blk driver does not provide discard feature flag, so the filesystems which built on top of the block device will not send discard command. This is okay for HDD backend, but it will impact the performance for SSD backend. Add a feature flag VIRTIO_BLK_F_DISCARD and command VIRTIO_BLK_T_DISCARD to extend exist virtio-blk protocol. virtio-blk protocol uses a single 8 bytes

Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo

Add virtqueue_add_sgs which is more general than virtqueue_add_buf, which makes virtio-scsi and virtio-blk nicer, then add virtqueue_add_inbuf and virtqueue_add_outbuf which handle the more general case, and finally delete virtqueue_add_buf(). I'm hoping this will be the final post of the whole series, and it can move from my pending-rebases tree into virtio-next. Thanks! Rusty. Paolo

> -----Original Message----- > From: Stefan Hajnoczi [mailto:stefanha at gmail.com] > Sent: Tuesday, March 28, 2017 4:20 AM > To: Liu, Changpeng <changpeng.liu at intel.com> > Cc: virtio-dev at lists.oasis-open.org; virtualization at lists.linux-foundation.org; linux- > kernel at vger.kernel.org; hch at lst.de; qemu-devel at nongnu.org > Subject: Re: [PATCH] virtio-blk:

> -----Original Message----- > From: Stefan Hajnoczi [mailto:stefanha at gmail.com] > Sent: Tuesday, March 28, 2017 4:20 AM > To: Liu, Changpeng <changpeng.liu at intel.com> > Cc: virtio-dev at lists.oasis-open.org; virtualization at lists.linux-foundation.org; linux- > kernel at vger.kernel.org; hch at lst.de; qemu-devel at nongnu.org > Subject: Re: [PATCH] virtio-blk:

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi, all This version reworked on REQ_FLUSH and REQ_FUA support as suggested by Christoph and dropped the block core bits since Jens has picked them up. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%,

Hi, all This version reworked on REQ_FLUSH and REQ_FUA support as suggested by Christoph and dropped the block core bits since Jens has picked them up. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%,

In response to Avi's excellent analysis, I've updated virtio as promised (apologies for the delay, travel got in the way). === This attempts to implement a "virtual I/O" layer which should allow common drivers to be efficiently used across most virtual I/O mechanisms. It will no-doubt need further enhancement. The details of probing the device are left to hypervisor-specific

In response to Avi's excellent analysis, I've updated virtio as promised (apologies for the delay, travel got in the way). === This attempts to implement a "virtual I/O" layer which should allow common drivers to be efficiently used across most virtual I/O mechanisms. It will no-doubt need further enhancement. The details of probing the device are left to hypervisor-specific

Hi, all Changes in v7: - Using vbr->flags to trace request type - Dropped unnecessary struct virtio_blk *vblk parameter - Reuse struct virtblk_req in bio done function - Added performance data on normal SATA device and the reason why make it optional Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential

Hi, all Changes in v7: - Using vbr->flags to trace request type - Dropped unnecessary struct virtio_blk *vblk parameter - Reuse struct virtblk_req in bio done function - Added performance data on normal SATA device and the reason why make it optional Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential