[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190114165800-mutt-send-email-mst@kernel.org>
Date: Mon, 14 Jan 2019 16:59:27 -0500
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Joerg Roedel <joro@...tes.org>, Jason Wang <jasowang@...hat.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, hch@....de,
Joerg Roedel <jroedel@...e.de>
Subject: Re: [PATCH 1/3] swiotlb: Export maximum allocation size
On Mon, Jan 14, 2019 at 03:49:07PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 11, 2019 at 10:12:31AM +0100, Joerg Roedel wrote:
> > On Thu, Jan 10, 2019 at 12:02:05PM -0500, Konrad Rzeszutek Wilk wrote:
> > > Why not use swiotlb_nr_tbl ? That is how drivers/gpu/drm use to figure if they
> > > need to limit the size of pages.
> >
> > That function just exports the overall size of the swiotlb aperture, no?
> > What I need here is the maximum size for a single mapping.
>
> Yes. The other drivers just assumed that if there is SWIOTLB they would use
> the smaller size by default (as in they knew the limitation).
>
> But I agree it would be better to have something smarter - and also convert the
> DRM drivers to piggy back on this.
>
> Or alternatively we could make SWIOTLB handle bigger sizes..
Just a thought: is it a good idea to teach blk_queue_max_segment_size
to get the dma size? This will help us find other devices
possibly missing this check.
> >
> > Regards,
> >
> > Joerg
Powered by blists - more mailing lists