On Thu, 30 Jun 2011 23:56:17 +0200 Alexander Graf <ag...@suse.de> wrote:
> > 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? 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
