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 00:38:36 +0200

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.


Alex




reply via email to

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