similar to: [PATCH 0/5 v6] Fix virtio-blk issue with SWIOTLB

Hi, here is the next version of this patch-set. Previous versions can be found here: V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro at 8bytes.org/ V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro at 8bytes.org/ V3: https://lore.kernel.org/lkml/20190123163049.24863-1-joro at 8bytes.org/ V4: https://lore.kernel.org/lkml/20190129084342.26030-1-joro at 8bytes.org/

On Thu, Jan 31, 2019 at 05:33:58PM +0100, Joerg Roedel wrote: > Hi, > > here is the next version of this patch-set. Previous > versions can be found here: > > V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro at 8bytes.org/ > > V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro at 8bytes.org/ > > V3:

On Thu, Jan 31, 2019 at 05:33:58PM +0100, Joerg Roedel wrote: > Hi, > > here is the next version of this patch-set. Previous > versions can be found here: > > V1: https://lore.kernel.org/lkml/20190110134433.15672-1-joro at 8bytes.org/ > > V2: https://lore.kernel.org/lkml/20190115132257.6426-1-joro at 8bytes.org/ > > V3:

Hi Michael, On Tue, Feb 05, 2019 at 03:52:38PM -0500, Michael S. Tsirkin wrote: > On Thu, Jan 31, 2019 at 05:33:58PM +0100, Joerg Roedel wrote: > > Changes to v5 are: > > > > - Changed patch 3 to uninline dma_max_mapping_size() > > And this lead to problems reported by kbuild :( Hmm, I didn't get any kbuild emails for this series. Can you please forward it me so

On 11/21/2017 10:27 AM, Jens Axboe wrote: > On 11/21/2017 03:14 AM, Christian Borntraeger wrote: >> Bisect points to >> >> 1b5a7455d345b223d3a4658a9e5fce985b7998c1 is the first bad commit >> commit 1b5a7455d345b223d3a4658a9e5fce985b7998c1 >> Author: Christoph Hellwig <hch at lst.de> >> Date: Mon Jun 26 12:20:57 2017 +0200 >> >> blk-mq:

On 11/21/2017 10:27 AM, Jens Axboe wrote: > On 11/21/2017 03:14 AM, Christian Borntraeger wrote: >> Bisect points to >> >> 1b5a7455d345b223d3a4658a9e5fce985b7998c1 is the first bad commit >> commit 1b5a7455d345b223d3a4658a9e5fce985b7998c1 >> Author: Christoph Hellwig <hch at lst.de> >> Date: Mon Jun 26 12:20:57 2017 +0200 >> >> blk-mq:

On 11/21/2017 10:50 AM, Christian Borntraeger wrote: > > > On 11/21/2017 09:35 AM, Christian Borntraeger wrote: >> >> >> On 11/20/2017 09:52 PM, Jens Axboe wrote: >>> On 11/20/2017 01:49 PM, Christian Borntraeger wrote: >>>> >>>> >>>> On 11/20/2017 08:42 PM, Jens Axboe wrote: >>>>> On 11/20/2017 12:29 PM,

On 11/21/2017 10:50 AM, Christian Borntraeger wrote: > > > On 11/21/2017 09:35 AM, Christian Borntraeger wrote: >> >> >> On 11/20/2017 09:52 PM, Jens Axboe wrote: >>> On 11/20/2017 01:49 PM, Christian Borntraeger wrote: >>>> >>>> >>>> On 11/20/2017 08:42 PM, Jens Axboe wrote: >>>>> On 11/20/2017 12:29 PM,

When running a guest featuring a virtio-blk-pci protected with a virtual IOMMU we hit a NULL pointer dereference. This series removes the dma_max_mapping_size() call in virtio_max_dma_size when the device does not have any dma_mask set. A check is also added to early return in dma_addressing_limited() if the dma_mask is NULL. Eric Auger (2): dma-mapping: Protect dma_addressing_limited against

On 11/21/2017 11:12 AM, Christian Borntraeger wrote: > > > On 11/21/2017 07:09 PM, Jens Axboe wrote: >> On 11/21/2017 10:27 AM, Jens Axboe wrote: >>> On 11/21/2017 03:14 AM, Christian Borntraeger wrote: >>>> Bisect points to >>>> >>>> 1b5a7455d345b223d3a4658a9e5fce985b7998c1 is the first bad commit >>>> commit

On 11/21/2017 11:12 AM, Christian Borntraeger wrote: > > > On 11/21/2017 07:09 PM, Jens Axboe wrote: >> On 11/21/2017 10:27 AM, Jens Axboe wrote: >>> On 11/21/2017 03:14 AM, Christian Borntraeger wrote: >>>> Bisect points to >>>> >>>> 1b5a7455d345b223d3a4658a9e5fce985b7998c1 is the first bad commit >>>> commit

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%,

On 11/21/2017 09:14 PM, Jens Axboe wrote: > On 11/21/2017 01:12 PM, Christian Borntraeger wrote: >> >> >> On 11/21/2017 08:30 PM, Jens Axboe wrote: >>> On 11/21/2017 12:15 PM, Christian Borntraeger wrote: >>>> >>>> >>>> On 11/21/2017 07:39 PM, Jens Axboe wrote: >>>>> On 11/21/2017 11:27 AM, Jens Axboe wrote:

On 11/21/2017 09:14 PM, Jens Axboe wrote: > On 11/21/2017 01:12 PM, Christian Borntraeger wrote: >> >> >> On 11/21/2017 08:30 PM, Jens Axboe wrote: >>> On 11/21/2017 12:15 PM, Christian Borntraeger wrote: >>>> >>>> >>>> On 11/21/2017 07:39 PM, Jens Axboe wrote: >>>>> On 11/21/2017 11:27 AM, Jens Axboe wrote:

On 11/21/2017 08:30 PM, Jens Axboe wrote: > On 11/21/2017 12:15 PM, Christian Borntraeger wrote: >> >> >> On 11/21/2017 07:39 PM, Jens Axboe wrote: >>> On 11/21/2017 11:27 AM, Jens Axboe wrote: >>>> On 11/21/2017 11:12 AM, Christian Borntraeger wrote: >>>>> >>>>> >>>>> On 11/21/2017 07:09 PM, Jens Axboe wrote:

On 11/21/2017 08:30 PM, Jens Axboe wrote: > On 11/21/2017 12:15 PM, Christian Borntraeger wrote: >> >> >> On 11/21/2017 07:39 PM, Jens Axboe wrote: >>> On 11/21/2017 11:27 AM, Jens Axboe wrote: >>>> On 11/21/2017 11:12 AM, Christian Borntraeger wrote: >>>>> >>>>> >>>>> On 11/21/2017 07:09 PM, Jens Axboe wrote:

On 11/21/2017 09:21 PM, Jens Axboe wrote: > On 11/21/2017 01:19 PM, Christian Borntraeger wrote: >> >> On 11/21/2017 09:14 PM, Jens Axboe wrote: >>> On 11/21/2017 01:12 PM, Christian Borntraeger wrote: >>>> >>>> >>>> On 11/21/2017 08:30 PM, Jens Axboe wrote: >>>>> On 11/21/2017 12:15 PM, Christian Borntraeger wrote:

On 11/21/2017 09:21 PM, Jens Axboe wrote: > On 11/21/2017 01:19 PM, Christian Borntraeger wrote: >> >> On 11/21/2017 09:14 PM, Jens Axboe wrote: >>> On 11/21/2017 01:12 PM, Christian Borntraeger wrote: >>>> >>>> >>>> On 11/21/2017 08:30 PM, Jens Axboe wrote: >>>>> On 11/21/2017 12:15 PM, Christian Borntraeger wrote:

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