linux-kernel - Re: [PATCH 01/34] AMD IOMMU: add Kconfig entry

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:	Fri, 27 Jun 2008 19:20:30 +0200
From:	Joerg Roedel <joro@...tes.org>
To:	Muli Ben-Yehuda <muli@...ibm.com>
Cc:	Andi Kleen <andi@...stfloor.org>, Adrian Bunk <bunk@...nel.org>,
	Joerg Roedel <joerg.roedel@....com>, tglx@...utronix.de,
	mingo@...hat.com, linux-kernel@...r.kernel.org,
	iommu@...ts.linux-foundation.org, bhavna.sarathy@....com,
	Sebastian.Biemueller@....com, robert.richter@....com
Subject: Re: [PATCH 01/34] AMD IOMMU: add Kconfig entry

On Fri, Jun 27, 2008 at 01:12:01PM -0400, Muli Ben-Yehuda wrote:
> On Fri, Jun 27, 2008 at 07:05:46PM +0200, Joerg Roedel wrote:
> > On Fri, Jun 27, 2008 at 12:59:47PM -0400, Muli Ben-Yehuda wrote:
> > > On Fri, Jun 27, 2008 at 06:54:30PM +0200, Joerg Roedel wrote:
> > > 
> > > > True. At least for the case without device isolation I have some
> > > > optimizations in mind which will minimize the performance
> > > > tradeoff. I hope to have them ready for 2.6.28 :)
> > > 
> > > Do you mean the case where you have a single I/O address space which
> > > is shared by all devices?
> > 
> > Yes. I think this will be the case used most when IOMMU is used for
> > virtualization
> 
> Could you elaborate on what you mean here? I assume you're thinking
> one I/O address space for the host, and one I/O address space per
> guest with assigned devices?

I think we can create an address space which almost direct-maps the
physical memory and let some room free for the aperture at the beginning
(say 64MB). If a mapping request arrives the code looks if it has to do
mapping (physical address of memory to map is in the first 64MB or
not in the device address range). If this is not the case it simply
returns the physical address as dma_addr. otherwise it does the
expensive mapping. This way we could minimize the default overhead which
we will get with an IOMMU and still use it for virtualization and as a
GART replacement.

> > and to handle devices with limited DMA address ranges.
> 
> I'd be pretty surprised if you'll find such devices on machines which
> will have AMD's IOMMU...

Think of 32bit PCI devices in a host with more than 4GB memory :)

Cheers,

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