[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190115175418.GA11402@lst.de>
Date: Tue, 15 Jan 2019 18:54:18 +0100
From: Christoph Hellwig <hch@....de>
To: Joerg Roedel <joro@...tes.org>
Cc: Christoph Hellwig <hch@....de>,
"Michael S . Tsirkin" <mst@...hat.com>,
Jason Wang <jasowang@...hat.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Jens Axboe <axboe@...nel.dk>,
virtualization@...ts.linux-foundation.org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
iommu@...ts.linux-foundation.org, jfehlig@...e.com,
jon.grimm@....com, brijesh.singh@....com, jroedel@...e.de
Subject: Re: [PATCH 2/3] dma: Introduce dma_max_mapping_size()
On Tue, Jan 15, 2019 at 05:23:22PM +0100, Joerg Roedel wrote:
> Right, I thought about that too, but didn't find a generic way to check
> for all the cases. There are various checks that could be done:
>
> 1) Check if SWIOTLB is initialized at all, if not, return
> SIZE_MAX as the limit. This can't be checked from dma-direct
> code right now, but could be easily implemented.
Yes, this is the low hanging fruit.
> 2) Check for swiotlb=force needs to be done.
>
> 3) Check whether the device can access all of available RAM. I
> have no idea how to check that in an architecture independent
> way. It also has to take memory hotplug into account as well
> as the DMA mask of the device.
>
> An easy approximation could be to omit the limit if the
> dma-mask covers all of the physical address bits available
> on the platform. It would require to pass the dma-mask as an
> additional parameter like it is done in dma_supported().
>
> Any better ideas for how to implement 3)?
And yeah, this is hard. So I'd just go for the low hanging fruit
for now and only implement 1) with a comment mentioning that
we are a little pessimistic.
Powered by blists - more mailing lists