Here's a short-to-medium term alternative to moving all of the ARMCPU
cp_regs hash table to the ARMCPUClass, so that we're no longer leaving
dangling pointers to freed objects encoded in the compiled
TranslationBlocks.  (I still think we ought to do less work at
object_{init,realize}, but that may be a much longer term project.)

Instead of giving the helper a direct pointer, pass the cpreg hash key,
which will be constant across cpus.  Perform this lookup in the existing
helper_access_check_cp_reg (which had a return value going spare), or a
new helper_lookup_cp_reg.  The other cp_regs functions are unchanged,
because they still get a pointer.

This ought to be enough to re-instate Alex's linux-user patch
to free the cpu object after thread termination.


r~


Richard Henderson (2):
  target/arm: Reorg do_coproc_insn
  target/arm: Look up ARMCPRegInfo at runtime

 target/arm/helper.h        |  11 +-
 target/arm/translate.h     |   7 +
 target/arm/op_helper.c     |  27 ++-
 target/arm/translate-a64.c |  49 +++--
 target/arm/translate.c     | 430 +++++++++++++++++++------------------
 5 files changed, 285 insertions(+), 239 deletions(-)

-- 
2.34.1

On Fri, 6 Jan 2023 at 19:45, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Here's a short-to-medium term alternative to moving all of the ARMCPU
> cp_regs hash table to the ARMCPUClass, so that we're no longer leaving
> dangling pointers to freed objects encoded in the compiled
> TranslationBlocks.  (I still think we ought to do less work at
> object_{init,realize}, but that may be a much longer term project.)
>
> Instead of giving the helper a direct pointer, pass the cpreg hash key,
> which will be constant across cpus.  Perform this lookup in the existing
> helper_access_check_cp_reg (which had a return value going spare), or a
> new helper_lookup_cp_reg.  The other cp_regs functions are unchanged,
> because they still get a pointer.
>
> This ought to be enough to re-instate Alex's linux-user patch
> to free the cpu object after thread termination.



Applied to target-arm.next, thanks.

-- PMM

Ping.

r~

On 1/6/23 09:44, Richard Henderson wrote:
> Here's a short-to-medium term alternative to moving all of the ARMCPU
> cp_regs hash table to the ARMCPUClass, so that we're no longer leaving
> dangling pointers to freed objects encoded in the compiled
> TranslationBlocks.  (I still think we ought to do less work at
> object_{init,realize}, but that may be a much longer term project.)
> 
> Instead of giving the helper a direct pointer, pass the cpreg hash key,
> which will be constant across cpus.  Perform this lookup in the existing
> helper_access_check_cp_reg (which had a return value going spare), or a
> new helper_lookup_cp_reg.  The other cp_regs functions are unchanged,
> because they still get a pointer.
> 
> This ought to be enough to re-instate Alex's linux-user patch
> to free the cpu object after thread termination.
> 
> 
> r~
> 
> 
> Richard Henderson (2):
>    target/arm: Reorg do_coproc_insn
>    target/arm: Look up ARMCPRegInfo at runtime
> 
>   target/arm/helper.h        |  11 +-
>   target/arm/translate.h     |   7 +
>   target/arm/op_helper.c     |  27 ++-
>   target/arm/translate-a64.c |  49 +++--
>   target/arm/translate.c     | 430 +++++++++++++++++++------------------
>   5 files changed, 285 insertions(+), 239 deletions(-)
>

On Mon, 16 Jan 2023 at 20:16, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> Ping.

What did you think of my suggestion in the other thread of hashing
the info we need to determine the cpreg set (ID regs, feature flags,
etc) and using that to look up whether we've already created a
cpreg hashtable for this config? If we did that, we could refcount
the cpreg hashtable and only free it when all CPUs are done with
it, which would mean we don't need this indirection.

thanks
-- PMM

On 1/17/23 00:28, Peter Maydell wrote:
> On Mon, 16 Jan 2023 at 20:16, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> Ping.
> 
> What did you think of my suggestion in the other thread of hashing
> the info we need to determine the cpreg set (ID regs, feature flags,
> etc) and using that to look up whether we've already created a
> cpreg hashtable for this config? If we did that, we could refcount
> the cpreg hashtable and only free it when all CPUs are done with
> it, which would mean we don't need this indirection.

I thought it a decent idea, but not small.

While we currently have a struct for some isar regs, we'd want a larger struct containing 
every bit of info that wants hashing.  I think it would take 40-50 patches to get all of 
the properties etc moved out of ARMCPU and CPUARMState.

Anyway, I didn't want to leave the user-only thread leak blocked in the meantime.


r~