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
| ||
|
Date: Tue, 31 Mar 2009 11:07:36 +0200 From: Joakim Tjernlund <Joakim.Tjernlund@...nsmode.se> To: Scott Wood <scottwood@...escale.com> Cc: Li Yang <leoli@...escale.com>, linuxppc-dev@...abs.org, netdev@...r.kernel.org, pku.leo@...il.com Subject: Re: [PATCH] ucc_geth: Rework the TX logic. Scott Wood <scottwood@...escale.com> wrote on 30/03/2009 21:32:23: > > Joakim Tjernlund wrote: > >> different since descriptors are in MURAM which is ioremap()ed -- though > >> switching to a cacheable mapping with barriers should be a performance > >> improvement. > > > > I always thought that MURAM was very fast. The whole reason to have BDs in > > MURAM is that it is faster than normal RAM, at least that is what I > > thought. > > Yeah, on second thought it probably wouldn't be worth it. There's also > the question of under what circumstances the QE's MURAM accesses will be > cache-coherent. I am a bit confused, what isn't worth it? Currently MURAM isn't used by ucc_geth, but it is easy to change. Swap MEM_PART_SYSTEM to MEM_PART_MURAM, however, just tried that and the driver stopped working. I known this worked earlier because I tried it and I even think I sent a patch to Leo. What choices do we have, I see three: 1) MEM_PART_SYSTEM, as today. 2) MEM_PART_MURAM. I guess this should be uncacheable memory? 3) as gianfar, dma_alloc_coherent(). I presume this is uncacheable memory? My guess would be 2 or 3. Do they have the same synchronization sematics? > > As for the CPU not reordering guarded+cache inhibited accesses, that > initially seemed to be true for the new arch stuff (book3e/book3s, but > not really, see below), but the classic arch documentation only > guarantees stores to such regions to be in-order (and the > explicitly-specified operation of eieio on I+G accesses wouldn't make > much sense if they were already guaranteed to be in-order). > > Then I looked at the EREF to see what older book E documents had to say > on the issue, and it suggests that when the architecture document says > "out of order", it really means "speculative" (and reading the arch > doc's definition of "out of order" seems to confirm this -- redefining > terms is bad, m'kay?). So it seems that the simple answer is no, > guarded storage is not guaranteed to be in order, unless the only thing > that can cause an out-of-order access is speculative execution. Very informative, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists