Re: [PATCH 1/2] x86 swiotlb: Verify we can perform the remapping requested.

[ebiederm@xmission.com (Eric W. Biederman)]

FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> writes:

> On Mon, 24 Oct 2011 08:07:31 -0700
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>
>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> writes:
>> 
>> > On Mon, Oct 17, 2011 at 02:19:18PM -0700, Eric W. Biederman wrote:
>> >> 
>> >> Recently I had a driver try with a peculiar 2G dma memory limit.
>> >> It failed in weird and strange ways because my bounce buffers were
>> >> being allocated above 2G where the driver could not reach, and
>> >> no error was reported when the mappings were setup.
>> >
>> > OK, so the overflow buffer was used instead.. which presumarily
>> > also was allocated above the 2G? That seems to point that
>> > alloc_bootmem_low_pages is not doing its job?
>> 
>> I just looked alloc_bootmem_low_pages allocates memory below
>> ARCH_ADDRESS_LIMIT which for everything except s390 is 4G.
>> 
>> I know I was mostly using the amd gart driver.  So I may be mistaken
>> that the swiotlb driver had the same issue.  However my only solution
>> at the time was to boot with mem=2G.  So I believe the swiotlb did
>> have this issue.
>> 
>> Mostly the patch was.  Hmm.  That looks stupid not wiring up the
>> swiotlb address space limit check when someone has already written it.
>
> http://www.gossamer-threads.com/lists/linux/kernel/1333685?do=post_view_threaded#1333685
>
> swiotlb isn't designed to handle hardware having odd dma mask (e.g. 2G
> or something). Such device needs the own bouncing mechanism.

I have no problem with that with not supporting weird dma masks.

There is a perfectly fine method to report an unsupported dma mask
programmatically that just needs a trivial code change to be wired up.
I just want the method to be wired up on x86 so that we fail gracefully,
instead of mysteriously.

Eric