From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YseK3-0008Il-D8 for qemu-devel@nongnu.org; Wed, 13 May 2015 17:36:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YseJz-0002qS-Cv for qemu-devel@nongnu.org; Wed, 13 May 2015 17:36:11 -0400 Received: from mail-qk0-x22e.google.com ([2607:f8b0:400d:c09::22e]:35626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YseJz-0002qK-8g for qemu-devel@nongnu.org; Wed, 13 May 2015 17:36:07 -0400 Received: by qkgy4 with SMTP id y4so37892387qkg.2 for ; Wed, 13 May 2015 14:36:06 -0700 (PDT) Sender: Richard Henderson Message-ID: <5553C3C2.9070101@twiddle.net> Date: Wed, 13 May 2015 14:36:02 -0700 From: Richard Henderson 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> In-Reply-To: Content-Type: text/plain; charset=windows-1252 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" , Leon Alrae Cc: Yongbok Kim , peter.maydell@linaro.org, qemu-devel@nongnu.org, afaerber@suse.de On 05/13/2015 02:21 PM, Maciej W. Rozycki wrote: > On Wed, 13 May 2015, Leon Alrae wrote: > >>> Certainly we do. It's all in softmmu_template.h. >> >> 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. This patch set *is* doing too much work for loads, since the loads can simply be issued, and the result written back to the register at the end after all have succeeded. r~