From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbU8G-0005VV-W6 for qemu-devel@nongnu.org; Fri, 27 Mar 2015 09:17:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbU8D-0002ru-Ni for qemu-devel@nongnu.org; Fri, 27 Mar 2015 09:17:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54265) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbU8D-0002rq-Iq for qemu-devel@nongnu.org; Fri, 27 Mar 2015 09:17:01 -0400 Message-ID: <55155845.5070306@redhat.com> Date: Fri, 27 Mar 2015 14:16:53 +0100 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: <20150327123223.GB19483@toto> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: "Edgar E. Iglesias" Cc: Peter Maydell , Peter Crosthwaite , Patch Tracking , QEMU Developers , Greg Bellows , =?windows-1252?Q?Alex_Benn=E9e?= , Richard Henderson 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. Paolo > > For 1 to be useful, I think it would have to be combined with some > kind of return info that can point out where in the magic splitting > of large or unaligned transactions that things went wrong. > > Probably overkill at the moment... > > Cheers, > Edgar >