linux-kernel - Re: Intel IOMMU (and IOMMU for Virtualization) performances

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 7 Jun 2008 00:36:59 +0300
From:	Muli Ben-Yehuda <muli@...ibm.com>
To:	Grant Grundler <grundler@...gle.com>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	linux-kernel@...r.kernel.org, mgross@...ux.intel.com,
	linux-scsi@...r.kernel.org
Subject: Re: Intel IOMMU (and IOMMU for Virtualization) performances

On Fri, Jun 06, 2008 at 02:28:36PM -0700, Grant Grundler wrote:

> Historically the IOMMUs needed physically contiguous memory and
> resizing essentially meant quiescing all DMA, moving the IO Pdir
> data to the new bigger location, allocating a new bitmap and cloning
> the state into that as well, and then resuming DMA operations. The
> DMA quiesce requirement effectively meant a reboot. My understanding
> of Vt-d is the ranges can be added range at a time and thus can be
> easily resized.

VT-d uses a multi-level page-table, so there would be no problem
resizing.

> But it will mean more complex logic in the IOMMU bitmap handling for
> a domain which owns multiple bitmaps and thus a slightly higher CPU
> utilization cost. At least that's my guess. I'm not working on any
> IOMMU code lately...

The logic seems pretty simple to me, all we need to do is keep track
of how many entries are currently allocated in the bitmap vs. the size
of the bitmap. Once we get to the half-way point, double the size of
the bitmap. Having said that, I'm not sure it's worth it, and have no
plans to implement it :-)

Cheers,
Muli
--
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/