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 <m...@redhat.com> 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 <kra...@redhat.com> 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
