> On 16 Jan 2015, at 09:07, Jan Kiszka <jan.kis...@siemens.com> wrote: > > On 2015-01-16 08:25, Mark Burton wrote: >> >>> 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 …. > > Yes, I didn't patched anything towards multi-threaded SMP. Main reason: > there was no answer on how to emulated the memory models of that target > architecture over the host one which is mandatory if you let the > emulated CPUs run unsynchronized in parallel. Did this change? >
No - we just decided to stop pressing the button… I think this is the ‘x86 on ARM’ issue ? - our plan is to get ARM of x86 working (or that class), and the worry about the other way round. I dont see why SMP ARM on X86 wouldn’t work with your patch? Cheers Mark. >> >>> >>>>>> 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 >> :-)) > > See above regarding the potential dimension. > > Jan > > -- > Siemens AG, Corporate Technology, CT RTC ITP SES-DE > Corporate Competence Center Embedded Linux +44 (0)20 7100 3485 x 210 +33 (0)5 33 52 01 77x 210 +33 (0)603762104 mark.burton
