linux-kernel - Re: [PATCH 3/3] x86/iommu: use __GFP

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:	Mon, 29 Sep 2008 23:11:19 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	mingo@...e.hu
Cc:	joerg.roedel@....com, mingo@...hat.com, tglx@...utronix.de,
	hpa@...or.com, linux-kernel@...r.kernel.org,
	fujita.tomonori@....ntt.co.jp
Subject: Re: [PATCH 3/3] x86/iommu: use __GFP_ZERO instead of memset for
	GART

On Mon, 29 Sep 2008 10:56:47 +0200
Ingo Molnar <mingo@...e.hu> wrote:

> 
> * Joerg Roedel <joerg.roedel@....com> wrote:
> 
> > On Sat, Sep 27, 2008 at 08:18:55PM +0200, Ingo Molnar wrote:
> > > 
> > > another thing:
> > > 
> > > How hard would it be to add an CONFIG_IOMMU_DEBUG option that forces as 
> > > many DMA requests to go via the IOMMU as possible?
> > > 
> > > This slows things down of course so it's only for debugging - but it 
> > > also makes sure that we utilize the IOMMU code to the maximum - which is 
> > > not normally the case.
> > > 
> > > Would be nice to have it .config driven (default-disabled), so that 
> > > -tip's randconfig testing can stumble upon it every now and then. I've 
> > > got GART test-systems - this way we could find certain types of IOMMU 
> > > breakages sooner.
> > 
> > For AMD IOMMU I disabled the round-robin allocator to stress-test the 
> > code. This means that the address allocation bitmap is always 
> > traversed from the first bit. In consequence the TLB flushing is 
> > stressed a lot (both in hardware and software) because the same DMA 
> > addresses are used again and again. For testing I hardcoded it into 
> > the driver but I can also make it depend on CONFIG_IOMMU_DEBUG.
> 
> yes - could you please make a new option for it, 
> CONFIG_IOMMU_DEBUG_FORCE=y or so - and cover all iommus that support it?

I'm not sure we are talking about the same thing. Surely, I and Joerg
are talking different things.

GART driver doesn't need to use the IOMMU hardware at all times. GART
does a virtual mapping only when necessary (a device needs to handle
an address that it can't access to). But as I wrote, if you use
iommu=force, GART driver always use the IOMMU hardware.


Other x86 IOMMU drivers always use the IOMMU hardware. Except for
Intel VT-D, they manage free virtual I/O space in the round-robin
manner with the bitmap algorithm to avoid frequent IOTLB flush. Joerg
said he tested AMD IOMMU driver with the round-robin manner disabled
so AMD IOMMU driver uses the same virtual I/O space with lots of IOTLB
flush.
--
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/