From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54263) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1C6p-0001eu-GY for qemu-devel@nongnu.org; Wed, 17 Dec 2014 05:45:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1C6i-0001Xx-TJ for qemu-devel@nongnu.org; Wed, 17 Dec 2014 05:45:35 -0500 Received: from cantor2.suse.de ([195.135.220.15]:38845 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1C6i-0001Xd-Mr for qemu-devel@nongnu.org; Wed, 17 Dec 2014 05:45:28 -0500 Message-ID: <54915EC6.2050708@suse.de> Date: Wed, 17 Dec 2014 11:45:26 +0100 From: Alexander Graf MIME-Version: 1.0 References: <1418721234-9588-1-git-send-email-fred.konrad@greensocs.com> <54915A76.3000408@greensocs.com> <54915AE8.3010809@suse.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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@listserver.greensocs.com, Peter Maydell , QEMU Developers , Paolo Bonzini , =?windows-1252?Q?Llu=EDs_Vilanova?= , =?windows-1252?Q?KONRAD_Fr=E9d=E9ric?= On 17.12.14 11:31, Mark Burton wrote: > >> On 17 Dec 2014, at 11:28, Alexander Graf wrote: >> >> >> >> On 17.12.14 11:27, Frederic Konrad wrote: >>> On 16/12/2014 17:37, Peter Maydell wrote: >>>> On 16 December 2014 at 09:13, wrote: >>>>> From: KONRAD Frederic >>>>> >>>>> This adds a lock to avoid multiple exclusive access at the same time >>>>> in case of >>>>> TCG multithread. >>> Hi Peter, >>> >>>> This feels to me like it's not really possible to review on >>>> its own, since you can't see how it fits into the design of >>>> the rest of the multithreading support. >>> true the only thing we observe is that it didn't change anything right now. >>> >>>> The other approach here rather than having a pile of mutexes >>>> in the target-* code would be to have TCG IR support for >>>> "begin critical section"/"end critical section". Then you >>>> could have the main loop ensure that no other CPU is running >>>> at the same time as the critical-section code. (linux-user >>>> already has an ad-hoc implementation of this for the >>>> exclusives.) >>>> >>>> -- PMM >>>> >>> What do you mean by TCG IR? >> >> TCP ops. The nice thing is that TCG could translate those into >> transactions if the host supports them as well. >> > > Hows that different in reality from what we have now? > Cheers > Mark. The current code can't optimize things in TCG. There's a good chance your TCG host implementation can have an optimization pass that creates host cmpxchg instructions or maybe even transaction blocks out of the critical sections. Alex