Message ID | 20230106194451.1213153-1-richard.henderson@linaro.org |
---|---|
Headers | show |
Series | target/arm: Look up ARMCPRegInfo at runtime | expand |
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~
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