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

[Alexander Graf]

On 01.07.2011, at 00:11, Scott Wood wrote:

> On Thu, 30 Jun 2011 23:56:17 +0200
> Alexander Graf <address@hidden> wrote:
> 
>> 
>> On 30.06.2011, at 23:46, Scott Wood wrote:
>> 
>>> On Thu, 30 Jun 2011 23:34:37 +0200
>>> Alexander Graf <address@hidden> wrote:
>>> 
>>>> We could just keep an internal counter that memorizes how much memory is 
>>>> locked and sets the bit after exceeding the fake cache size.
>>> 
>>> And keep track of unlocks, decrementing the counter only if the address was
>>> already locked...  seems better to keep it simple and just be honest about
>>> the failure until a real need for trickery arises.
>>> 
>>>> The only problem I could see remaining is that CAR could potentially fail, 
>>>> as it can access addresses in cache directly that don't have to have 
>>>> underlying RAM mapped. However, I'd hope that only firmware does this and 
>>>> we usually don't execute real firmware in qemu :)
>>> 
>>> This is a case where it would be nice for the guest to see the failure
>>> indication, if we're lucky enough that it bothers to check.
>>> 
>>> But yeah, it's unlikely to happen outside of firmware.
>>> 
>>>> Also, lock set instructions seem to raise DSIs, so we need to generate 
>>>> some loads that don't go anywhere.
>>> 
>>> Yes.
>>> 
>>> Note that dcbtstls is treated as a store, which is a little trickier.
>> 
>> Not that much. It should be enough to simply do:
>> 
>>  st(addr, ld(addr));
>> 
>> no?
> 
> 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?

> I assume races among threads are taken care of by some mechanism whereby
> qemu only takes an interrupt on target instruction boundaries (does/will
> qemu simulate guest SMP?),

Qemu generates SMP by rescheduling guest CPUs on translation block boundaries. 
So instructions are always guaranteed to be atomic. Of course, that means only 
a single host CPU is used.

There has been some work by different people to get rid of that limitation, but 
so far none has proven to be generic enough.

> 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 :).


Alex