linux-kernel - RE: [PATCH] Microblaze: implement dma-coherent API and refactorcache flush code.

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:	Tue, 06 May 2008 10:14:59 +1000
From:	John Williams <john.williams@...alogix.com>
To:	Stephen Neuendorffer <stephen.neuendorffer@...inx.com>
Cc:	arnd@...db.de, linux-arch@...r.kernel.org,
	John Linn <linnj@...inx.com>, matthew@....cx,
	will.newton@...il.com, drepper@...hat.com,
	microblaze-uclinux@...e.uq.edu.au, grant.likely@...retlab.ca,
	Michal Simek <monstr@...str.eu>, linux-kernel@...r.kernel.org
Subject: RE: [PATCH] Microblaze: implement dma-coherent API and
	refactorcache flush code.


> > Does the DMA API insist upon the dma_cache_sync call to guarantee
> > sensible results?  If so, your implementation looks fine.  If not,
> then
> > the results will clearly be bogus as there's nothing magical about the
> > memory being allocated in dma_alloc.
> 
> Yes, in fact this is one of the keys to getting the lltemac driver to
> work right.  see Documentation/DMA-API.txt
> 
> > To that end, can it just call kmalloc(), and similarly kfree() for
> > dma_free?
> 
> My understanding is that on other architectures (x86, for instance)
> 'dma' memory ensures other things, like it's accessible in PCI memory
> space.  On microblaze, there's nothing really special about dma memory,
> but you get the API as a chunk.

Sure - what I meant is can dma_alloc just call kmalloc to do it's work?
 
> > I'd still like to see the uncached shadow stuff make a return one day,
> > it is an effective way of solving the problem, we'll just need to find
> a
> > cleaner way to implement it.  A linear walk through the cache to
> > invalidate is so slow, it destroys any benefit gained from DMA in the
> > first place.
> 
> I think it's definitely a simple way of solving the problem (in fact,
> the version of the code that's currently at git.xilinx.com includes it).
> Would it be better dealt with at the page level, rather than at the
> address level, then one of the architecture-reserved flags could be used
> for it?
> If it really does have value, then I want to make sure it goes in, along
> with bits in EDK that make it straightforward to use.  For me, the
> biggest barrier to using it is understanding exactly what assumptions it
> is making on the hardware, and making those assumptions bulletproof.

I agree.  Michal did some work on that when he did the initial DTS stuff
with us over the (southern) summer this year.  We looked at ways to
validate the HW design and Kconfig params to make sure that
uncached_shadow worked as expected.

If forget now the outcome, there's plenty of ways to get it wrong.

It would be easy at runtime to do some validation tests - write to a
pointer, cache flush (noop..), read back from the twiddled pointer, make
sure it matches.  Repeat a few times until you're happy it wasn't a
fluke, that sort of thing.

John

> 
> Steve
> 
> 
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663


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