On 01.07.2011, at 00:11, Scott Wood wrote: > 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?
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
