On Tue, 2007-05-01 at 21:47 +1000, Nick Piggin wrote: > Rohit Seth wrote: > > > > > > It is invalidating any entries (containing same physical address) in both I > > and D caches. Any dirty lines in D cache are written back to memory before > > getting invalidated (ofcourse). > > OK. (should it be issuing both fc and fc.i to be robust in case a > new implementation doesn't flush the dcache with fc.i?) >
For the Itanium case specifically, you only want to invalidate a stale icache line. Once that is done, next time icache will pick the correct updated contents. > > >>There are supposedly no icache lines at that point[**]: > > > > > > For this bug to trigger there has to be a (stale) entry in icache containing > > the old contents of a page that just got updated by kernel as explicit > > copying of data (DMAs are coherent on ia64, meaning if a device were to > > write to memory then architecture guarnatees that both I and D caches are > > invalidated). > > So if we have a dirty dcache line for a given physical address, > it will _always_ be the case that a subsequent icache load will > find that dirty data? yes for ia64. -rohit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
