> On 15 Jan 2015, at 22:41, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > On 15/01/2015 21:53, Mark Burton wrote: >>> Jan said he had it working at least on ARM (MusicPal). >> >> yeah - our problem is when we enable multi-threads - which I dont believe >> Jan did… > > Multithreaded TCG, or single-threaded TCG with SMP?
He mentions SMP, - I assume thats single-threaded …. > >>>> One thing I wonder - why do we need to go to the extent of mutexing >>>> in the TCG like this? Why can’t you simply put a mutex get/release on >>>> the slow path? If the core is going to do ‘fast path’ access to the >>>> memory, - even if that memory was IO mapped - would it matter if it >>>> didn’t have the mutex? >>> >>> Because there is no guarantee that the memory map isn't changed by a >>> core under the feet of another. The TLB (in particular the "iotlb") is >>> only valid with reference to a particular memory map. >> >>> >>> Changes to the memory map certainly happen in the slow path, but lookups >>> are part of the fast path. Even an rwlocks is too slow for a fast path, >>> hence the plan of going with RCU. >> >> Could we arrange the world such that lookups ‘succeed’ (the wheels >> dont fall off) -ether getting the old value, or the new, but not getting >> rubbish - and we still only take the mutex if we are going to make >> alterations to the MM itself? (I have’t looked at the code around that… >> so sorry if the question is ridiculous). > > That's the definition of RCU. :) Look at the docs in > http://permalink.gmane.org/gmane.comp.emulators.qemu/313929 for more > information. :) Ahh - I see ! > > It's still not trivial to make it 100% correct, but at the same time > it's not too hard to prepare something decent to play with. Also, most > of the work can be done with KVM so it's more or less independent from > what you guys have been doing so far. Yes - the issue is if we end up relying on it. But - I see what you mean - these 2 things can ‘dovetail’ together “independently” - so - Jan’s patch will be good for now, and then later we can use RCU to make it work more generally (and more efficiently). So - our only small problem is getting Jan’s patch to work for multi-thread :-)) Cheers Mark. > > Paolo +44 (0)20 7100 3485 x 210 +33 (0)5 33 52 01 77x 210 +33 (0)603762104 mark.burton
