On 01/07/2011 17:05, Alexander Graf wrote: > > On 01.07.2011, at 16:59, Fabien Chouteau wrote: > >> On 01/07/2011 00:38, Alexander Graf wrote: >>> >>> On 01.07.2011, at 00:32, Scott Wood wrote: >>> >>>> On Fri, 1 Jul 2011 00:28:19 +0200 >>>> Alexander Graf <ag...@suse.de> wrote: >>>> >>>>> >>>>> On 01.07.2011, at 00:23, Scott Wood wrote: >>>>> >>>>>> On Fri, 1 Jul 2011 00:18:22 +0200 >>>>>> Alexander Graf <ag...@suse.de> wrote: >>>>>> >>>>>>> >>>>>>> On 01.07.2011, at 00:11, Scott Wood wrote: >>>>>>> >>>>>>>> Almost, but what if we have write permission but not read? >>>>>>> >>>>>>> How would you write back data from a cache line when you haven't read >>>>>>> it earlier? >>>>>> >>>>>> The CPU can read it. The program can't. >>>>> >>>>> Hrm. We can always just call the check manually and trigger the >>>>> respective interrupt :). >>>> >>>> Yep. A little trickier, but doable. >>>> >>>>>>>> but what about a race with DMA from the I/O thread? >>>>>>> >>>>>>> That'd simply be broken, but I don't quite see how it wouldn't with >>>>>>> real hardware either :). >>>>>> >>>>>> Real hardware doesn't generate a load/store sequence that the program >>>>>> didn't >>>>>> ask for -- where's the breakage? >>>>> >>>>> Real hardware flushes whatever contents are in that cache line to RAM, >>>>> no? So it would collide with the DMA just as much. Or am I missing >>>>> something? >>>> >>>> If the DMA happens after the cache line is fetched, it'll be flushed, >>>> whether locked or not. But that's different from losing some of what the >>>> device wrote. >>> >>> Ah, so DMA flushes even locked cache lines? Then it makes sense. Well, I >>> guess the best choice here really is to merely do a manual storage >>> protection check and be done with it. >>> >> >> Well, this is far beyond the scope of my knowledge of e500 and the current >> patch is sufficient for me, so I will let you implement this if you want >> to... > > Well, all it needs is to call mmubooke206_get_physical_address on the address > (or each page of the destination) with access_type set to write and check for > the result. If it's protected, inject a DSI (see cpu_ppc_handle_mmu_fault). > > But yeah, I can try and see if I get around to implementing it. No promises > though. Do you have a test case I can verify this against?
No, I just implemented these no-oped instructions to get rid of an illegal instruction exception while running u-boot on my emulated p2010. -- Fabien Chouteau
