Re: [PATCH] Remove unassigned_access CPU hook

[Peter Maydell]

On Fri, 20 Sep 2019 at 14:36, Philippe Mathieu-Daudé <address@hidden> wrote:
>
> Hi Peter,
>
> On 9/20/19 2:50 PM, Peter Maydell wrote:
> > All targets have now migrated away from the old unassigned_access
> > hook to the new do_transaction_failed hook. This means we can remove
> > the core-code infrastructure for that hook and the code that calls it.
> >
> > Signed-off-by: Peter Maydell <address@hidden>
> > ---
> > Based-on: <address@hidden>
> > ("[PATCH v1 0/2] RISC-V: Convert to do_transaction_failed hook")
> >  -- the last of the conversions isn't in master yet, but I figured
> > I might as well put the cleanup patch out for review.
>
> Hopefully this hook is neither implemented by the RX/AVR targets posted
> on the list recently.

Good point -- luckily a quick email archive search says they don't
try to implement the old hook.

> > @@ -1291,9 +1287,6 @@ static void unassigned_mem_write(void *opaque, hwaddr 
> > addr,
> >  #ifdef DEBUG_UNASSIGNED
> >      printf("Unassigned mem write " TARGET_FMT_plx " = 0x%"PRIx64"\n", 
> > addr, val);
> >  #endif
> > -    if (current_cpu != NULL) {
> > -        cpu_unassigned_access(current_cpu, addr, true, false, 0, size);
> > -    }
> >  }
>
> Having unassigned_mem_read/unassigned_mem_write with
> CPUReadMemoryFunc/CPUWriteMemoryFunc prototype only used for logging is
> rather confusing. We can kill them and use trace events instead in
> memory_region_dispatch_read/write. I'll send a follow-up cleanup patch.

You still need some function to do the "return 0" on read, though, don't you?
(Having unassigned_mem_accepts returning false also leaves me a bit
confused about when these functions would actually get called, now
I look at the code again...)

thanks
-- PMM