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]
Date:	Wed, 27 Jun 2007 17:26:50 +0200
From:	Andi Kleen <ak@...e.de>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
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

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.

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.

-Andi
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ