[Top][All Lists]
[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