[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Remove unassigned_access CPU hook
From: |
Peter Maydell |
Subject: |
Re: [PATCH] Remove unassigned_access CPU hook |
Date: |
Fri, 20 Sep 2019 14:44:03 +0100 |
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