From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Lfu-0007u3-ML for qemu-devel@nongnu.org; Fri, 02 Mar 2012 01:09:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3Lfs-0004TM-6U for qemu-devel@nongnu.org; Fri, 02 Mar 2012 01:09:06 -0500 Received: from plane.gmane.org ([80.91.229.3]:57954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Lfr-0004SS-Vk for qemu-devel@nongnu.org; Fri, 02 Mar 2012 01:09:04 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S3Lfq-0006po-HN for qemu-devel@nongnu.org; Fri, 02 Mar 2012 07:09:02 +0100 Received: from 213.33.220.118 ([213.33.220.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Mar 2012 07:09:02 +0100 Received: from e.voevodin by 213.33.220.118 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Mar 2012 07:09:02 +0100 From: Evgeny Voevodin Date: Fri, 02 Mar 2012 10:08:50 +0400 Message-ID: <4F5063F2.5060908@samsung.com> References: <1330340818-4125-1-git-send-email-e.voevodin@samsung.com> <1330344787-14482-1-git-send-email-e.voevodin@samsung.com> <4F4C4643.2080007@samsung.com> <20120301075146.GA2937@cs.nctu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit In-Reply-To: <20120301075146.GA2937@cs.nctu.edu.tw> Subject: Re: [Qemu-devel] [PATCH v2] TCG: Convert global variables to be TLS. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Peter Maydell , i.mitsyanko@samsung.com, kyungmin.park@samsung.com, d.solodkiy@samsung.com, m.kozlov@samsung.com On 01.03.2012 11:51, 陳韋任 wrote: >> If you're serious about multithreading TCG then I think the first >> steps are: >> * fix existing race conditions >> * think very hard >> * come up with an overall design for what you're proposing > > As COREMU [1] point out, current QEMU atomic instruction emulation approach is > problematic. For example, guest application might use x86 xchg instruction to > implement spin lock/unlock (addr is a shared memory space). > > > spin_unlock: spin_lock: > > try: > r10 = 1; > xchg addr, r10; > if (r10 == 0) > goto success; > *addr = 0; fail: > pause; > if (*addr != 0) > goto fail; > > goto try; > > success: > > > After QEMU translation, guest xchg instruction becomes > > spin_unlock: spin_lock: > > helper_lock; > > *addr = 0; T0 = r10; > T1 = *addr; > *addr = T0; > r10 = T1; > > helper_unlock; > > You can the see the atomicity on which spin lock/unlock rely is broken. > "*addr = 0" can happened in the between of helper_lock/helper_unlock. > COREMU solve this by using a lightway software transaction memory to emulate > atomic instructions. I think this issue is quite important if we want to make > TCG multithreaded, right? Is there a better way to solve this? > > Regards, > chenwj > > [1] > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.187.6011&rep=rep1&type=pdf > In COREMU implementation they rely on support of single-word CAS instructions by the host architecture. And if such support presents, we can use CASN algorithm if we need multiple-word CAS. So, this approach limits supported host architectures. The general question - is there some host which QEMU can run on and which doesn't support CAS? -- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow R&D center, Samsung Electronics e-mail: e.voevodin@samsung.com