Re: [PATCHv5 1/2] block: accumulate memory segment gaps per bio

Hi Keith,

On 8/17/26 5:04 PM, Keith Busch wrote:
> On Mon, Aug 17, 2026 at 03:23:14PM +0200, Eric Auger wrote:
>>>  
>>> diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c
>>> index 449950029872a..94d3461b5bc8e 100644
>>> --- a/block/blk-mq-dma.c
>>> +++ b/block/blk-mq-dma.c
>>> @@ -79,8 +79,7 @@ static bool blk_map_iter_next(struct request *req, struct blk_map_iter *iter,
>>>  static inline bool blk_can_dma_map_iova(struct request *req,
>>>  		struct device *dma_dev)
>>>  {
>>> -	return !((queue_virt_boundary(req->q) + 1) &
>>> -		dma_get_merge_boundary(dma_dev));
>>> +	return !(req_phys_gap_mask(req) & dma_get_merge_boundary(dma_dev));
>>
>> I observe a regression on RHEL due to that change in
>> blk_can_dma_map_iova() with a 64kB host. This also occurs with upstream
>> (7.2-rc7).
>>
>> For an NVME device blk_can_dma_map_iova() now returns trues while it did
>> not before. And it seems it shouldn't because it then causes some errors
>> on the dma_iova_link() path due to unaligned iova:
>>
>> [ 4486.655564] iommu: unaligned: iova 0x14c34000 pa 0x000010764d790000
>> size 0x1d0000 min_pagesz 0x10000
>>
>> It occurs when launching a 4kB guest with virtio-blk.
>>
>> I traced:
>> nvme 0015:01:00.0: req_phys_gap_mask=0xffffffffffff0000,
>> queue_virt_boundary+1=0x1, get_merge_boundary=0xffff
> 
> The first thing that looks odd to me here is the page offset in the iova
> isn't reflected in the pa, so I think something in the construction
> isn't setting it up the first vector correctly.
> 
> Thanks for the notice, I'm looking into it.
Please let me know if you want me to trace some stuff specifically.

Thanks!

Eric


>