We will roll a patch for this approach shortly. For the ‘better’ approach - I think it’s something we will consider doing…. but as you say, one thing at a time. I dont think it will be too bad to implement, given what already exists in the tlb’s - (except if we have to protect (for some architecture or other) against non-atomic reads from an address marked atomic, I think). I think we can treat this independently (unless we discover that it won’t work without :-) )
Cheers Mark. > On 15 Dec 2014, at 14:28, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On 15 December 2014 at 12:56, Mark Burton <mark.bur...@greensocs.com> wrote: >> One proposal is ‘simply’ to add a mutex around this code, such >> that multi-threaded TCG will correctly update/read these saved >> address/values. >> This _should_ maintain the status-quo. Things that were broken >> before will remain broken, nothing new should break. The concern >> is that the fact that the TCG was previously uni-threaded MAY be >> masking problems with this code that we are not taking into account. > > Personally I would start out with this approach. We're going to > need a "do this whole sequence atomically wrt other guest CPUs" > mechanism anyway, so it's not implementing something we wouldn't > otherwise need. And it's the simple thing to do. It's certainly > possible to do a more architecturally correct ld/st exclusive > implementation along the lines of how we manage TB invalidation > with the dirty bitmap, but if we can do without it then we > should try to keep the scope of this project constrained: it's > a big enough job as it is. > > -- PMM +44 (0)20 7100 3485 x 210 +33 (0)5 33 52 01 77x 210 +33 (0)603762104 mark.burton