From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmAxw-0000Fc-Gq for qemu-devel@nongnu.org; Mon, 10 Jun 2013 18:53:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UmAxv-0003bU-FJ for qemu-devel@nongnu.org; Mon, 10 Jun 2013 18:53:32 -0400 Date: Tue, 11 Jun 2013 00:53:17 +0200 From: "Edgar E. Iglesias" Message-ID: <20130610225317.GD5991@smtp.vpn> References: <1370439748-18092-1-git-send-email-hpoussin@reactos.org> <51B2E26F.8030106@msgid.tls.msk.ru> <51B563CC.5040907@redhat.com> <20130610170649.GA31588@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Qemu-trivial] [PATCH] ioport/memory: check that both .read and .write callbacks are defined List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: "Michael S. Tsirkin" , qemu-trivial@nongnu.org, Michael Tokarev , qemu-devel@nongnu.org, =?iso-8859-1?Q?Herv=E9?= Poussineau , Gerd Hoffmann , Paolo Bonzini On Tue, Jun 11, 2013 at 08:30:12AM +1000, Peter Crosthwaite wrote: > Hi Michael, > > On Tue, Jun 11, 2013 at 3:06 AM, Michael S. Tsirkin wrote: > > On Mon, Jun 10, 2013 at 07:14:45PM +1000, Peter Crosthwaite wrote: > >> Hi, > >> > >> On Mon, Jun 10, 2013 at 3:27 PM, Gerd Hoffmann wrote: > >> > Hi, > >> > > >> >> Maybe instead (or in addition to), we should provide a dummy > >> >> read or write functions -- instead of fixing each such occurence > >> >> to use its own dummy function > >> > > >> > Makes sense, especially for write where we can just ignore what the > >> > guest attempts to write. Not sure we can have a generic handler for > >> > reads. Maybe two, one which returns 0xff and one which returns 0x00. > >> > > >> > >> FWIW, I have one in my tree that qemu_log(LOG_GUEST_ERROR's such > >> accesses that I use for unimplemented devices. It's worthwhile to trap > >> such accesses and speaking for the Xilinx LQSPI case, my preference is > >> for some form of failure rather than silent write-ignore. And can we > >> have an option where a invalid writes have consistent behavior with > >> unassigned accesses? > >> > >> Regards, > >> Peter > > > > Probably not a good idea. Ignoring unassigned addresses > > is very handy for compatibility: we can run new guests > > on old qemu and They don't crash or log errors. > > > > Log errors do not crash QEMU even if they are enabled. They just make > noise and even then only if you pass -d guest_errors (which we do as > pretty much habit now for this reason). It is the compromise solution > between those of us who want to ignore them and those of us who need > to know about them. The default behavior will still be to ignore > accesses with no action. Hi Peter, I agree that it's very useful to be able to track these accesses. My impression was that we could track accesses to unmapped (by spec) areas via guest-errors and unmapped/unimplemented areas (due to lack of qemu models) via LOG_UNIMP? As the latter are not really guest-errors.. Cheers, Edgar