From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqmWo-0001nc-De for qemu-devel@nongnu.org; Tue, 09 Aug 2011 09:39:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqmWl-0001Ti-Qf for qemu-devel@nongnu.org; Tue, 09 Aug 2011 09:39:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqmWl-0001TF-Ej for qemu-devel@nongnu.org; Tue, 09 Aug 2011 09:39:27 -0400 Message-ID: <4E412E7A.6000607@redhat.com> Date: Tue, 09 Aug 2011 15:56:26 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E40F628.9050505@redhat.com> <1312880570-12530-1-git-send-email-avi@redhat.com> <4E40FD3A.70208@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1.1 09/24] omap_gpmc/nseries/tusb6010: convert to memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 08/09/2011 12:41 PM, Peter Maydell wrote: > On 9 August 2011 10:26, Avi Kivity wrote: > > On 08/09/2011 12:23 PM, Peter Maydell wrote: > >> > >> On 9 August 2011 10:02, Avi Kivity wrote: > >> > +static const MemoryRegionOps omap_gpmc_ops = { > >> > + .read = omap_gpmc_read, > >> > + .write = omap_gpmc_write, > >> > + .endianness = DEVICE_NATIVE_ENDIAN, > >> > + .valid = { > >> > + .min_access_size = 4, > >> > + .max_access_size = 4, > >> > + }, > >> > }; > >> > >> Does this give debug trace output for missized accesses? > > > > Only after we implement and configure a debug policy in memory.c > > > >> That's the main point of the badread/badwrite functions... > > > > These are broken now, aren't they? > > They successfully print a message, which as I say is the > main point. The OMAP TRM typically says the behaviour isn't > defined for wrong-size accesses, so guest code doing it is > broken anyhow and so the error in the current implementation > is IMHO not so serious. > > I think if (as here) it turns out that we need more functionality > in memory.c then we should be implementing it, not silently > dropping things in the conversion process. > Okay. I'll update the patch to forward to the badread/badwrite functions on bad size. -- error compiling committee.c: too many arguments to function