linux-kernel - Re: dma_mapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4682AF15.5040906@goop.org>
Date:	Wed, 27 Jun 2007 14:40:21 -0400
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andi Kleen <ak@...e.de>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jan Beulich <jbeulich@...ell.com>,
	Tony Luck <tony.luck@...el.com>,
	Muli Ben-Yehuda <muli@...ibm.com>
Subject: Re: dma_mapping_ops for i386

Andi Kleen wrote:
> On Wednesday 27 June 2007 16:15:17 Jeremy Fitzhardinge wrote:
>   
>> Andi Kleen wrote:
>>     
>>> Ok, if you can do it without ifdefs. 
>>>   
>>>       
>> That should be OK.  All the existing i386 mapping operations would just 
>> have their own ops structure, right?
>>     
>
> I just mention it because many people's ideas of merging files
> seem to add lots of ifdefs which is imho the totally wrong thing
> to do.
>
>   
>>> And no swiotlb on i386; that is something that is completely broken
>>> in upstream Xen and needs to be fixed properly anyways.
>>>   
>>>       
>> Hm, OK.  I'm not really familiar with the issues here.  What are they?  
>> Looks like Jan has made a number of Xen-ish changes to lib/swiotlb.c; 
>> are more changes be needed?
>>     
>
> See the recent "quiet down swiotlb warnings" thread which uncovered
> quite some corpses in Xen's current IO setup.
>
> Xen apparently bounces for multi page IOs which get merged from block
> lists because the block layer doesn't know they are not really 
> continuous in machine memory.
>
> Proper fix is to tell the block layer to not merge in the first
> place instead.
>
> And probably some similar mechanism for network drivers that limits
> MTUs.
>   

Well, I think there are two issues here.  One is that two 
pseudo-physical pages won't necessarily be contigious in bus space, 
because of the pseudo-phys to machine mapping.

The second problem is that devices which can't address all machine 
physical memory (ie, 32-bit PCI devices on machines with >4G memory) 
will need to have bouncebuffers established for them.  Device drivers 
won't necessarily be able to do it because they're not really aware of 
machine addresses.

> Maybe we'll still need a simple bouncing mechanism for other obscure
> devices with large IOs then, but I would very much prefer if it wasn't 
> swiotlb and could be solved some other way.
>   

I think 32-bit-only devices are a bigger concern, no?

    J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/