From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1HTw-00060k-QZ for qemu-devel@nongnu.org; Wed, 17 Dec 2014 11:29:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1HTs-0002Zt-47 for qemu-devel@nongnu.org; Wed, 17 Dec 2014 11:29:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49066) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1HTr-0002Yo-SO for qemu-devel@nongnu.org; Wed, 17 Dec 2014 11:29:44 -0500 Date: Wed, 17 Dec 2014 16:20:40 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20141217162039.GC31071@work-vm> References: <1418721234-9588-1-git-send-email-fred.konrad@greensocs.com> <54915A76.3000408@greensocs.com> <54915AE8.3010809@suse.de> <54915EC6.2050708@suse.de> <8B6B4BF9-3400-4125-8571-F4EF9F12AA89@greensocs.com> <5491666A.7060001@suse.de> <54916829.3020200@redhat.com> <7200ECC8-49FE-4CEB-B41E-AC15093554B1@greensocs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7200ECC8-49FE-4CEB-B41E-AC15093554B1@greensocs.com> Subject: Re: [Qemu-devel] [RFC PATCH] target-arm: protect cpu_exclusive_*. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Burton Cc: mttcg@greensocs.com, Peter Maydell , QEMU Developers , Alexander Graf , Paolo Bonzini , Llu?s Vilanova , KONRAD Fr?d?ric * 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 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