Re: [Qemu-devel] [PATCH] Add e500 instructions dcblc, dcbtls and dcbtstl as no-op

[Fabien Chouteau]

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 <address@hidden> wrote:
>>>>
>>>>>
>>>>> On 01.07.2011, at 00:23, Scott Wood wrote:
>>>>>
>>>>>> On Fri, 1 Jul 2011 00:18:22 +0200
>>>>>> Alexander Graf <address@hidden> 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