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:	Fri, 09 May 2014 10:58:50 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Arnd Bergmann <arnd@...db.de>, linux-doc@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Joerg Roedel <joro@...tes.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Liviu Dudau <Liviu.Dudau@....com>,
	linux-kernel@...r.kernel.org,
	James Bottomley <jbottomley@...allels.com>,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH v2 4/5] iommu: Use dma_addr_t for IOVA arguments

On Thu, 2014-05-08 at 14:30 -0600, Bjorn Helgaas wrote:
> I doubt there would be a noticeable performance effect since these are
> relatively low-frequency interfaces (map, unmap, report_fault), 

That point of view makes me sad.

There are people who care deeply about the performance of IOMMU API
map/unmap. It isn't used *just* for virtual machines any more. See
drivers/infiniband/hw/usnic/usnic_uiom.c for example.

(Yes, they probably ought to be using SVM. But that's not going to
happen on the current generation of hardware.)

I also hold out *some* hope for consolidating the map/unmap functions
for the IOMMU and DMA APIs at some point. The main difference is that
the DMA API allocates an IOVA for itself, while the IOMMU API is given
the bus address too.

So we end up with duplicated map/unmap functions, *and* all the IOMMU
drivers implementing their own IOVA allocator.

I'd like to see if we can have a single IOVA allocator for the DMA API
to use, and let IOMMU drivers implement *just* the IOMMU API style of
map/unmap functions where they're *told* where to put it.

Which is another reason I'm not quite ready to shrug and say that IOMMU
API map/unmap performance is uninteresting. Although since it's
predicated here by "on 32-bit systems", I'm not actually throwing my
toys out of the pram... :)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5745 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ