Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*.

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Mark Burton (mark.burton@greensocs.com) wrote:
> Actually - I dont see any other option.
> Playing with the ideas - it seems to me that if we were to implement ?generic? Lock/unlock instructions which could then somehow we ?combined? with loads/stores then we would be relying on an optimisation step to ?notice? that this could be combined into e.g. a store EX on ARM, or whatever. That strikes me as risky .
> 
> But then - if we add load/store exclusive type operations - thats great for e.g. ARM on X86, but does it really cover other architectures well?
> 
> I am worried that if we go this path, we will soon end up with a lot of architecturally specific TCG ops?.

I'd expect you to end up with two types;
   1) the ARM/MIPS/PPC split load/store,
   2) the x86/s390/ARMv8.1 compare exchange.

The tricky thing is to pick a sane set of TCG ops that is a good fit into each
of the two groups on different targets.

Dave


> 
> Cheers
> 
> Mark.
> 
> > On 17 Dec 2014, at 12:25, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > 
> > 
> > 
> > On 17/12/2014 12:18, Alexander Graf wrote:
> >> 
> >> So I think the best way to go forward would be to add transaction_start
> >> and transaction_end opcodes to TCG and implement them as mutex locks
> >> today. When you get the chance to get yourself a machine that supports
> >> actual TM, try to replace them with transaction start/end blocks and
> >> have the normal mutex code as fallback if the transaction fails.
> > 
> > Or implement load_locked/store_conditional TCG ops.  They can be
> > implemented as transactions, hardware ll/sc, or something slow that uses
> > the MMU.
> > 
> > Paolo
> 
> 
> 	 +44 (0)20 7100 3485 x 210
>  +33 (0)5 33 52 01 77x 210
> 
> 	+33 (0)603762104
> 	mark.burton
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK