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

[Alexander Graf]

On 30.06.2011, at 18:17, Scott Wood wrote:

> On Thu, 30 Jun 2011 10:25:31 +0200
> Fabien Chouteau <address@hidden> wrote:
> 
>> On 28/06/2011 18:20, Scott Wood wrote:
>>> On Tue, 28 Jun 2011 10:17:39 +0200
>>> Fabien Chouteau <address@hidden> wrote:
>>> 
>>>> Why do you want to set this bit? Can't we consider that the instruction is
>>>> always effective?
>>> 
>>> But it's not.  Why claim it is, in the absence of some specific workload
>>> that needs to be fooled (which could take many different forms, not all of
>>> which are appropriate defaults)?
>> 
>> Reading the e500 manual again, it's not clear to me what can make the
>> L1CSR0[CUL] to be set. If you have a better understanding, can you please
>> explain?
>> 
> 
> L1CSR0[CUL] is set whenever a lock set instruction fails to lock
> (typically because all ways of the set are already locked).  Since we don't
> support cache locking in qemu, these instructions always fail, and thus CUL
> should always be set.
> 
> Regarding what behavior would maximize compatibility, while it's
> conceivable that some program could break if it sees the bit set when it
> was expecting to be able to succeed, also consider a program that might
> keep locking until it sees the bit set to determine how much cache it can
> lock.

We could just keep an internal counter that memorizes how much memory is locked 
and sets the bit after exceeding the fake cache size.

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

Also, lock set instructions seem to raise DSIs, so we need to generate some 
loads that don't go anywhere.


Alex