Re: [Qemu-devel] [PATCH] memory: Use standard log messages for unassigned memory read / write

[Stefan Weil]

Am 07.09.2016 um 23:29 schrieb Peter Maydell:
> On 7 September 2016 at 20:13, Stefan Weil <address@hidden> wrote:
> > The old log messages are implemented by conditional compilation
> > and not available by default.
> >
> > The new log messages can be enabled either by a command line option
> > (-d unimp) or in the QEMU monitor (log unimp).
> >
> > Signed-off-by: Stefan Weil <address@hidden>
> > ---
> >
> > The new code is very useful when implementing new platforms or
> > looking for problems with existing platforms which are only
> > partially emulated (I use it for Raspberry Pi).
> >
> > target-sparc/ldst_helper.c also uses DEBUG_UNASSIGNED
> > and could get similar code.
> >
> > Regards,
> > Stefan
> >
> >
> >  memory.c | 12 ++++--------
> >  1 file changed, 4 insertions(+), 8 deletions(-)

[...]

> > -#ifdef DEBUG_UNASSIGNED
> > -    printf("Unassigned mem write " TARGET_FMT_plx " = 0x%"PRIx64"\n", addr, 
> > val);
> > -#endif
> > +    qemu_log_mask(LOG_UNIMP, "%s " TARGET_FMT_plx " = 0x%" PRIx64 "\n",
> > +                  __func__, addr, val);
>
> Maybe this should be LOG_GUEST_ERROR rather than LOG_UNIMP ?

My first code used LOG_GUEST_ERROR. Of course a guest can try to access 
memory which is not available for the real hardware.

For my test object (Raspberry Pi), all unassigned memory accesses were 
not guest errors but unimplemented emulation in QEMU – that's why I 
changed from LOG_GUEST_ERROR to LOG_UNIMP.

A short test with i386 / x86_64 emulation also detected unassigned 
memory accesses (from BIOS) caused by an unimplemented debug device, so 
that was also not a guest error.

Even bad memory access caused by the guest might need special handling 
in QEMU, because the effect on real hardware can differ depending on the 
address range. So although in that case LOG_GUEST_ERROR would be fine, 
LOG_UNIMP matches as well.

It does not really matter whether the code uses LOG_UNIMP or 
LOG_GUEST_ERROR, as long as it is possible to enable such log messages. 
So whoever accepts this patch can simply replace that part if needed.

> >      if (current_cpu != NULL) {
> >          cpu_unassigned_access(current_cpu, addr, true, false, 0, size);
> >      }
> > --
> > 2.1.4
>
> Idle thought: would it be worth having an "unimplemented-thing"
> device which just existed to print LOG_GUEST_ERROR errors which
> included a string indicating what the missing device was? The
> board models would need to actually instantiate them in the
> right places (hopefully just one-liners) but that's easier than
> implementing lots of devices. And it would give us some
> documentation in the source of what's still missing in a board.

That's what I am currently doing for RPi.

The main problem is that some devices for a certain platform are not 
obvious, so you will miss them initially because of missing 
documentation. Example for RPi: the random number generator.
Example for x86: the hardware debug device accesses by the BIOS.

Cheers
Stefan