On 11/04/15 16:19, Ard Biesheuvel wrote: > On 4 November 2015 at 13:17, Cohen, Eugene <[email protected]> wrote: >>> The set/way operations are really only suitable for managing the caches >>> themselves >> >> This makes sense to me and I agree that the majority of developers should >> only be dealing with managing buffers and should only use the >> VA/address-range interface. >> > > OK. Does that mean you agree that blindly wiring up the generic > WriteBackDataCache/InvalidateDataCache entry points to set/way cache > maintenance is a bad idea? > >>> there are examples of architecturally compliant systems with system level >>> caches where cleaned data has been observed to only make it to main memory >>> if you clean by VA. >> >> I fully expect this given the nature of the ARM architecture - the scope >> architectural specifications stop at the interconnect so if somebody wants >> to implement wacky hardware then there's nothing to stop them. Presumably >> for whole-cache management some extra stuff is required on these systems to >> make it work - which is fine although not that helpful for interoperability >> purposes. >> >>> But seriously, I understand that there is a performance concern here, but >>> 'promoting' a clean by VA operation to clean by set/way really makes no >>> sense at all. >> >> Defaulting to safe/correct for all architectures makes sense to me. But it >> would be nice for those of us that understand our architectures (no system >> level caches, SMP config understood) to choose an option to turn on >> thresholding through a PCD setting or library class selection. >> > > The problem remains that VA and set/way ops are completely different > things. Each by-VA operation handles all copies of the same cacheline > throughout the cache hierarchy at once. The set/way ops, on the other > hand, traverse each cache level in turn, leaving a time window between > the completion of the L1 maintenance and the completion of the L2 > maintenance where speculative accesses resulting in L1 misses are > happily served from the L2 and allocated in L1 -- unless your MMU and > I-cache are off. This means the logic that promotes from VA to set/way > ops should take MMU and I-cache state into account as well, and I am > not sure you would want to go there.
Thanks for this great summary. So, why doesn't ARM provide instructions for flushing / invalidating the complete cache? Just curious. Thanks Laszlo > >>> I am not proposing to remove this functionality. >> >> Ok - I may have interpreted patch 4 as removing more than PoU but I can see >> it's just removing entire-cache flushing to PoU - this is fine by me since >> cache maintenance for code loading should always reference the relevant VAs. >> > > Indeed. > >> Editorial: I know there's been a lot of talk about what tools to use to >> review code and a lot of people like email - but for me it's hard for me to >> get proper context with 10 patches in email when I don't work on the code >> every day - I'd like to think if I saw these in a tool like gerrit I would >> have had proper context sooner. >> > > I personally quite like Gerrit, but I don't think we are likely to > start using it for EDK2. As Laszlo pointed out, I did not push out the > series to a public branch this time. I will make sure to do that for > the v2. > >> Thanks for the context - glad we have you working on this. :) >> > > Thanks. > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
