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

[Scott Wood]

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?

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?), but what about a race with DMA from the I/O
thread?

-Scott