qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] Add e500 instructions dcblc, dcbtls and dcbtstl as no-op
Date: Fri, 1 Jul 2011 17:05:05 +0200

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?


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]