From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq1kU-00081R-KJ for qemu-devel@nongnu.org; Wed, 06 May 2015 12:00:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yq1kQ-0004Y1-9M for qemu-devel@nongnu.org; Wed, 06 May 2015 12:00:38 -0400 Received: from greensocs.com ([193.104.36.180]:59519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yq1kP-0004Xq-PB for qemu-devel@nongnu.org; Wed, 06 May 2015 12:00:34 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mark Burton In-Reply-To: <554A386F.9030804@redhat.com> Date: Wed, 6 May 2015 18:00:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2FFE49ED-AB16-4D4B-B525-53B4D9BBC35F@greensocs.com> References: <1430926687-25875-1-git-send-email-a.rigo@virtualopensystems.com> <554A386F.9030804@redhat.com> Subject: Re: [Qemu-devel] [RFC 0/5] Slow-path for atomic instruction translation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: mttcg@greensocs.com, claudio.fontana@huawei.com, Alvise Rigo , QEMU Developers , Jani Kokkonen , tech@virtualopensystems.com By the way - would it help to send the atomic patch we did separately = from the whole MTTCG patch set? Or have you already taken a look at that - it=92s pretty short. Cheers Mark. > On 6 May 2015, at 17:51, Paolo Bonzini wrote: >=20 > On 06/05/2015 17:38, Alvise Rigo wrote: >> This patch series provides an infrastructure for atomic >> instruction implementation in QEMU, paving the way for TCG = multi-threading. >> The adopted design does not rely on host atomic >> instructions and is intended to propose a 'legacy' solution for >> translating guest atomic instructions. >>=20 >> The underlying idea is to provide new TCG instructions that guarantee >> atomicity to some memory accesses or in general a way to define = memory >> transactions. More specifically, a new pair of TCG instructions are >> implemented, qemu_ldlink_i32 and qemu_stcond_i32, that behave as >> LoadLink and StoreConditional primitives (only 32 bit variant >> implemented). In order to achieve this, a new bitmap is added to the >> ram_list structure (always unique) which flags all memory pages that >> could not be accessed directly through the fast-path, due to previous >> exclusive operations. This new bitmap is coupled with a new TLB flag >> which forces the slow-path exectuion. All stores which take place >> between an LL/SC operation by other vCPUs in the same memory page, = will >> fail the subsequent StoreConditional. >>=20 >> In theory, the provided implementation of TCG = LoadLink/StoreConditional >> can be used to properly handle atomic instructions on any = architecture. >>=20 >> The new slow-path is implemented such that: >> - the LoadLink behaves as a normal load slow-path, except for = cleaning >> the dirty flag in the bitmap. The TLB entries created from now on = will >> force the slow-path. To ensure it, we flush the TLB cache for the >> other vCPUs >> - the StoreConditional behaves as a normal store slow-path, except = for >> checking the state of the dirty bitmap and returning 0 or 1 whether = or >> not the StoreConditional succeeded (0 when no vCPU has touched the >> same memory in the mean time). >>=20 >> All those write accesses that are forced to follow the 'legacy' >> slow-path will set the accessed memory page to dirty. >>=20 >> In this series only the ARM ldrex/strex instructions are implemented. >> The code was tested with bare-metal test cases and with Linux, using >> upstream QEMU. >>=20 >> This work has been sponsored by Huawei Technologies Dusseldorf GmbH. >>=20 >> Alvise Rigo (5): >> exec: Add new exclusive bitmap to ram_list >> Add new TLB_EXCL flag >> softmmu: Add helpers for a new slow-path >> tcg-op: create new TCG qemu_ldlink and qemu_stcond instructions >> target-arm: translate: implement qemu_ldlink and qemu_stcond ops >=20 > That's pretty cool. >=20 > Paolo +44 (0)20 7100 3485 x 210 +33 (0)5 33 52 01 77x 210 +33 (0)603762104 mark.burton