On 30.06.2011, at 23:46, Scott Wood wrote: > On Thu, 30 Jun 2011 23:34:37 +0200 > Alexander Graf <ag...@suse.de> 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? Alex