search for: blk_queue_max_hw_sectors

Hi, For virtio block device, actually there is no a hard limit for max request size, and virtio_blk driver set -1 to blk_queue_max_hw_sectors(q, -1U);. But it doesn't work, because there is a default upper limitation BLK_DEF_MAX_SECTORS (1280 sectors). So this series want to add a new helper blk_queue_max_hw_sectors_no_limit to set a proper max reqeust size. Weiping Zhang (2): blk-setting: add new helper blk_queue_max_hw_sectors_n...

Hi, For virtio block device, actually there is no a hard limit for max request size, and virtio_blk driver set -1 to blk_queue_max_hw_sectors(q, -1U);. But it doesn't work, because there is a default upper limitation BLK_DEF_MAX_SECTORS (1280 sectors). So this series want to add a new helper blk_queue_max_hw_sectors_no_limit to set a proper max reqeust size. Weiping Zhang (2): blk-setting: add new helper blk_queue_max_hw_sectors_n...

On 4/5/18 4:09 AM, Weiping Zhang wrote: > Hi, > > For virtio block device, actually there is no a hard limit for max request > size, and virtio_blk driver set -1 to blk_queue_max_hw_sectors(q, -1U);. > But it doesn't work, because there is a default upper limitation > BLK_DEF_MAX_SECTORS (1280 sectors). So this series want to add a new helper > blk_queue_max_hw_sectors_no_limit to set a proper max reqeust size. > > Weiping Zhang (2): > blk-setting: add new hel...

...0x9c/0x1a8 >>> ... >>> [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8 >>> >>> Commit 9491ae4 caps the read-ahead request to a limit set by the backing >>> device. For virtio-blk, it is infinite (as set by the call to >>> blk_queue_max_hw_sectors in virtblk_probe). >>> >>> I'm not sure how to fix this. Setting an arbitrary sector limit in the >>> virtio-blk driver seems unfair to other users. Maybe we should check if >>> the device is behind a hardware IOMMU before using the DMA API? >> >>...

...0x9c/0x1a8 >>> ... >>> [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8 >>> >>> Commit 9491ae4 caps the read-ahead request to a limit set by the backing >>> device. For virtio-blk, it is infinite (as set by the call to >>> blk_queue_max_hw_sectors in virtblk_probe). >>> >>> I'm not sure how to fix this. Setting an arbitrary sector limit in the >>> virtio-blk driver seems unfair to other users. Maybe we should check if >>> the device is behind a hardware IOMMU before using the DMA API? >> >>...

...] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 > ... > [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8 > > Commit 9491ae4 caps the read-ahead request to a limit set by the backing > device. For virtio-blk, it is infinite (as set by the call to > blk_queue_max_hw_sectors in virtblk_probe). > > I'm not sure how to fix this. Setting an arbitrary sector limit in the > virtio-blk driver seems unfair to other users. Maybe we should check if > the device is behind a hardware IOMMU before using the DMA API? Hmm, this looks more like the virtio_block devi...

...] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 > ... > [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8 > > Commit 9491ae4 caps the read-ahead request to a limit set by the backing > device. For virtio-blk, it is infinite (as set by the call to > blk_queue_max_hw_sectors in virtblk_probe). > > I'm not sure how to fix this. Setting an arbitrary sector limit in the > virtio-blk driver seems unfair to other users. Maybe we should check if > the device is behind a hardware IOMMU before using the DMA API? Hmm, this looks more like the virtio_block devi...

Booting Linux on an ARM fastmodel containing an SMMU emulation results in an unexpected I/O page fault from the legacy virtio-blk PCI device: [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received: [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010 [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000 [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002 [

Booting Linux on an ARM fastmodel containing an SMMU emulation results in an unexpected I/O page fault from the legacy virtio-blk PCI device: [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received: [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010 [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000 [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002 [

...fo = gd->private_data; @@ -564,6 +565,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 sector_size) /* Hard sector size and max sectors impersonate the equiv. hardware. */ blk_queue_logical_block_size(rq, sector_size); + blk_queue_physical_block_size(rq, physical_sector_size); blk_queue_max_hw_sectors(rq, 512); /* Each segment in a request is up to an aligned page in size. */ @@ -667,7 +669,8 @@ static char *encode_disk_name(char *ptr, unsigned int n) static int xlvbd_alloc_gendisk(blkif_sector_t capacity, struct blkfront_info *info, - u16 vdisk_info, u16 sector_size) +...

...blk_status_t virtblk_result(struct virtblk_req *vbr) { switch (vbr->status) { @@ -730,8 +758,8 @@ static int virtblk_probe(struct virtio_device *vdev) /* We can handle whatever the host told us to handle. */ blk_queue_max_segments(q, vblk->sg_elems-2); - /* No real sector limit. */ - blk_queue_max_hw_sectors(q, -1U); + /* No real sector limit, use 512b (max_request_size << 10) >> 9 */ + blk_queue_max_hw_sectors_no_limit(q, max_request_size << 1); /* Host can optionally specify maximum segment size and number of * segments. */ -- 2.9.4

...uest_queue *q; int err, index; - u32 v, blk_size, sg_elems, opt_io_size; + u32 v, blk_size, max_size, sg_elems, opt_io_size; u16 min_io_size; u8 physical_block_exp, alignment_offset; @@ -826,14 +826,16 @@ static int virtblk_probe(struct virtio_device *vdev) /* No real sector limit. */ blk_queue_max_hw_sectors(q, -1U); + max_size = virtio_max_dma_size(vdev); + /* Host can optionally specify maximum segment size and number of * segments. */ err = virtio_cread_feature(vdev, VIRTIO_BLK_F_SIZE_MAX, struct virtio_blk_config, size_max, &v); if (!err) - blk_queue_max_segment_size(q, v);...

...ck_exp, alignment_offset; unsigned int queue_depth; + size_t max_dma_size; if (!vdev->config->get) { dev_err(&vdev->dev, "%s failure: config access disabled\n", @@ -1411,7 +1412,8 @@ static int virtblk_probe(struct virtio_device *vdev) /* No real sector limit. */ blk_queue_max_hw_sectors(q, UINT_MAX); - max_size = virtio_max_dma_size(vdev); + max_dma_size = virtio_max_dma_size(vdev); + max_size = max_dma_size > U32_MAX ? U32_MAX : max_dma_size; /* Host can optionally specify maximum segment size and number of * segments. */ -- 2.34.1

..... > >>> [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8 > >>> > >>> Commit 9491ae4 caps the read-ahead request to a limit set by the backing > >>> device. For virtio-blk, it is infinite (as set by the call to > >>> blk_queue_max_hw_sectors in virtblk_probe). > >>> > >>> I'm not sure how to fix this. Setting an arbitrary sector limit in the > >>> virtio-blk driver seems unfair to other users. Maybe we should check if > >>> the device is behind a hardware IOMMU before using the DMA AP...

Dear list, This is the V4 of the trim support for xen-blkfront/blkback, Now we move BLKIF_OP_TRIM to BLKIF_OP_DISCARD, and dropped all "trim" stuffs in the patches, and use "discard" instead. Also we updated the helpers of blkif_x86_{32|64}_request or we will meet problems using a non-native protocol. And this patch has been tested with both SSD and raw file, with SSD we will

...>] __virtblk_add_req+0x9c/0x1a8 >> ... >> [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8 >> >> Commit 9491ae4 caps the read-ahead request to a limit set by the backing >> device. For virtio-blk, it is infinite (as set by the call to >> blk_queue_max_hw_sectors in virtblk_probe). >> >> I'm not sure how to fix this. Setting an arbitrary sector limit in the >> virtio-blk driver seems unfair to other users. Maybe we should check if >> the device is behind a hardware IOMMU before using the DMA API? > > Hmm, this looks more li...

..._sgs+0x2ec/0x4e8 [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8 ... [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8 Commit 9491ae4 caps the read-ahead request to a limit set by the backing device. For virtio-blk, it is infinite (as set by the call to blk_queue_max_hw_sectors in virtblk_probe). I'm not sure how to fix this. Setting an arbitrary sector limit in the virtio-blk driver seems unfair to other users. Maybe we should check if the device is behind a hardware IOMMU before using the DMA API? Thanks, Jean-Philippe > Cc: Andy Lutomirski <luto at kernel....

..... > >>> [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8 > >>> > >>> Commit 9491ae4 caps the read-ahead request to a limit set by the backing > >>> device. For virtio-blk, it is infinite (as set by the call to > >>> blk_queue_max_hw_sectors in virtblk_probe). > >>> > >>> I'm not sure how to fix this. Setting an arbitrary sector limit in the > >>> virtio-blk driver seems unfair to other users. Maybe we should check if > >>> the device is behind a hardware IOMMU before using the DMA AP...

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/

...lk_queue_make_request(struct request_queue *, make_request_fn *); +extern void blk_queue_abort_queue(struct request_queue *, abort_queue_fn *); extern void blk_queue_bounce_limit(struct request_queue *, u64); extern void blk_limits_max_hw_sectors(struct queue_limits *, unsigned int); extern void blk_queue_max_hw_sectors(struct request_queue *, unsigned int); -- 1.7.10.1