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

Keith Busch <[email protected]>
Newsgroups org.kernel.vger.linux-block,org.infradead.lists.linux-nvme
Message-ID <aoMi6y2qsnRVembg@kbusch-mbp>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.