From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ysorl-0006oc-Q8 for qemu-devel@nongnu.org; Thu, 14 May 2015 04:51:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ysorg-0004Tw-Pu for qemu-devel@nongnu.org; Thu, 14 May 2015 04:51:41 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:14946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ysorg-0004Ob-K8 for qemu-devel@nongnu.org; Thu, 14 May 2015 04:51:36 -0400 Message-ID: <55546211.4020301@imgtec.com> Date: Thu, 14 May 2015 09:51:29 +0100 From: Leon Alrae MIME-Version: 1.0 References: <1431531457-17127-1-git-send-email-yongbok.kim@imgtec.com> <1431531457-17127-3-git-send-email-yongbok.kim@imgtec.com> <5553A5C4.6030902@twiddle.net> <5553ACF2.7050708@twiddle.net> <5553BB40.7050706@imgtec.com> <5553C3C2.9070101@twiddle.net> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 2/2] target-mips: Misaligned memory accesses for MSA List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Maciej W. Rozycki" , Richard Henderson Cc: Yongbok Kim , peter.maydell@linaro.org, qemu-devel@nongnu.org, afaerber@suse.de On 13/05/2015 23:54, Maciej W. Rozycki wrote: > On Wed, 13 May 2015, Richard Henderson wrote: > >>>> I believe the problem is that MSA vector register's size is 16-bytes >>>> (this DATA_SIZE isn't supported in softmmu_template) and MSA load/store >>>> is supposed to be atomic. >>> >>> Not really AFAICT. Here's what the specification says[1]: >>> >>> "The vector load instruction is atomic at the element level with no >>> guaranteed ordering among elements, i.e. each element load is an atomic >>> operation issued in no particular order with respect to the element's >>> vector position." >>> >>> and[2]: >>> >>> "The vector store instruction is atomic at the element level with no >>> guaranteed ordering among elements, i.e. each element store is an atomic >>> operation issued in no particular order with respect to the element's >>> vector position." >>> >>> so you only need to get atomic up to 8 bytes (with LD.D and ST.D, less >>> with the narrower vector elements), and that looks supported to me. >> >> There's "atomic" in the transactional sense, and then there's "atomic" in the >> visibility to other actors on the bus sense. >> >> Presumably Leon is talking about the first, wherein we must ensure all writes >> to both pages must succeed. Which just means making sure that both pages are >> present and writable before modifying any memory. > > I don't think we have. The specification is a bit unclear I must admit > and it also defines the details of vector load and store operations as > implementation dependent, so there's no further clarification. This is specified in "MIPS Architecture For Programmers Volume I-A: Introduction to the MIPS64 Architecture", Revision: 6.01, Imagination Technologies, Document Number: MD00083, August 20, 2014, p.142: "For example, a misaligned vector load instruction will never leave its vector destination register half written, if part of a page split succeeds and the other part takes an exception. It is either all done, or not at all." Leon