netdev - Re: network devices don't handle pci_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]

Date:	Thu, 7 Dec 2006 11:48:14 +0530
From:	"Amit S. Kale" <amitkale@...syssoft.com>
To:	Muli Ben-Yehuda <muli@...ibm.com>
Cc:	Stephen Hemminger <shemminger@...l.org>,
	Jeff Garzik <jeff@...zik.org>,
	"Amit S. Kale" <amitkale@...xen.com>, netdev@...r.kernel.org,
	brazilnut@...ibm.com, netxenproj@...syssoft.com, rob@...xen.com,
	romieu@...zoreil.com, sanjeev@...xen.com, wendyx@...ibm.com
Subject: Re: network devices don't handle pci_dma_mapping_error()'s

On Thursday 07 December 2006 01:03, Muli Ben-Yehuda wrote:
> On Wed, Dec 06, 2006 at 10:16:44AM -0800, Stephen Hemminger wrote:
> > I think it is really only an issue for drivers that turn on HIGH_DMA
> > and have limited mask values. The majority of drivers either only
> > handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know
> > the details of how we manage IOMMU, but doesn't mapping always work
> > for those drivers.
>
> It's up to an IOMMU (DMA-API) implementation to define what
> constitutes a mapping error, e.g., Calgary and GART on x86-64 will
> return bad_dma_address from the mapping functions when they run out of
> entries in the IO space, which can happen regardless of the mask.

We've seen IOMMU space running out on ia64 systems. Would this be the case 
with other 10G driver requiring IOMMU remapping? We need frequent map-unmap 
at near 10G throughput.

On the x86_64 boxes that don't feature iommu functionality (because the 
motherboard disables it or because Linux can't handle it) Linux bounce buffer 
framework automatically comes into picture. Could we have the same framework 
take over when IOMMU space is over? I don't think this is possible with 
present code, though. We probably can have fallback_dma_ops in addition to 
dma_ops.

-Amit
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html