On 17/05/2021 15:02, Richard Henderson wrote:
On 5/17/21 11:59 AM, Lucas Mateus Martins Araujo e Castro wrote:
I'm not completely sure how this should be handled, there's a
get_physical_address in mmu_helper.c but it's a static function and
divided by processor families instead of MMU types, so
get_physical_address_* should be a new function?
The new get_physical_address_* function would be a mmu-hash(32|64)
that do something like ppc_radix64_xlate and add a function to
mmu-book3s-v3 that call either the radix64 or the hash64 function and
also handle real mode access.
The entry points that we are concerned about are:
ppc_cpu_get_phys_page_debug
ppc_cpu_tlb_fill
Currently there is a hook, pcc->handle_mmu_fault, which is used by
ppc_cpu_tlb_fill, but is insufficiently general. We're going to
remove that hook.
We're going to add a new hook with the same interface as
ppc_radix64_xlate that will be used by both
ppc_cpu_get_phys_page_debug and ppc_cpu_tlb_fill.
So, just to make sure we understand, what we want to do is:
* take all the common code from *_handle_mmu_fault and put it in
ppc_cpu_tlb_fill
* take whatever is not common and hide it in an equivalent of
ppc_radix64_xlate
* make the 2 entry points only use these new functions, so we can
compile ppc_cpu_get_phys_page_debug
* move get_physical_address and all functions called by it somewhere
that will compile when we disable tcg (again, to compile
get_phys_page_debug)
Is that it? Sorry if this is very obvious, we never dealt with hardware
and mmu stuff before...
--
Bruno Piazera Larsen
Instituto de Pesquisas ELDORADO
<https://www.eldorado.org.br/?utm_campaign=assinatura_de_e-mail&utm_medium=email&utm_source=RD+Station>
Departamento Computação Embarcada
Analista de Software Trainee
Aviso Legal - Disclaimer <https://www.eldorado.org.br/disclaimer.html>
