On 05/07/2021 01:24, David Gibson wrote:
> Changed hash32 address translation to use the supplied mmu_idx, instead
> of using what was stored in the msr, for parity purposes (radix64
> already uses that).
Well.. parity and conceptual correctness. The translation is supposed
to use mmu_idx, not look at the CPU again to get the right context.
AFAIK there isn't a situation in hash32 where they'll get out of sync,
but nothing guarantees that.
Fair point, I can change the description if I do end up with a new version, but
I think the right approach is to duplicate the helper macros in
mmu-hash32.h for now. We can unify them later with a more thorough
review (which would probably involve creating a new header for things
common to all BookS family MMUs).
This doesn't work directly. I'd need to put in an ifndef PPC_MMU_BOOK3S_V3_H,
which also feels a bit dubious to me. I can go with whichever one you prefer
--
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>
