From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbUQ7-0007X9-St for qemu-devel@nongnu.org; Fri, 27 Mar 2015 09:35:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbUQ4-0001ol-K6 for qemu-devel@nongnu.org; Fri, 27 Mar 2015 09:35:31 -0400 Received: from mail-pd0-x22b.google.com ([2607:f8b0:400e:c02::22b]:33235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbUQ4-0001oJ-E5 for qemu-devel@nongnu.org; Fri, 27 Mar 2015 09:35:28 -0400 Received: by pdnc3 with SMTP id c3so96970062pdn.0 for ; Fri, 27 Mar 2015 06:35:27 -0700 (PDT) Date: Fri, 27 Mar 2015 23:35:22 +1000 From: "Edgar E. Iglesias" Message-ID: <20150327133522.GC19483@toto> References: <1426526422-28338-1-git-send-email-peter.maydell@linaro.org> <1426526422-28338-2-git-send-email-peter.maydell@linaro.org> <20150327120228.GA19483@toto> <5515489F.40102@redhat.com> <20150327123223.GB19483@toto> <55155845.5070306@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55155845.5070306@redhat.com> Subject: Re: [Qemu-devel] [RFC 1/5] memory: Define API for MemoryRegionOps to take attrs and return status List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , Peter Crosthwaite , Patch Tracking , QEMU Developers , Greg Bellows , Alex =?iso-8859-1?Q?Benn=E9e?= , Richard Henderson On Fri, Mar 27, 2015 at 02:16:53PM +0100, Paolo Bonzini wrote: > > > On 27/03/2015 13:32, Edgar E. Iglesias wrote: > >>> Is this related to masters relying on the memory frameworks magic > >>> handling of unaliged accesses? > >> > >> Not necessarily, you can get the same just by doing a large write that > >> spans multiple MemoryRegions. See the loop in address_space_rw. > > > > Right, this is another case of "magic" memory handling that allows masters > > to issue unnatural transactions and rely on the memory framework to > > split things up. > > In these cases aren't the masters trading accuracy (including error > > handling accuracy) for performance or model simplicity? > > Yes. There are no "natural" transactions beyond 32 or 64-bit accesses. > > > It could maybe be useful to have a flag so masters can say one of the > > following (could be encoded in the memattrs): > > 1. Stop at first error and return. > > 2. Keep going after errors and give me the OR result of all errors. > > It could just be a length pointer in the same vein as > address_space_map's. If NULL, keep going. If not NULL, stop and return. > Good point, thanks. Cheers, Edgar