Re: [Qemu-devel] [Qemu-trivial] [PATCH] ioport/memory: check that both .read and .write callbacks are defined

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

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 <mst@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 <kraxel@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