[RFC PATCH 05/10] arm64: mm: avoid __pa translations in early_fixmap_init

[Catalin Marinas]

On Tue, Feb 23, 2016 at 06:43:37PM +0100, Ard Biesheuvel wrote:
> On 23 February 2016 at 18:32, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Tue, Feb 23, 2016 at 06:27:27PM +0100, Ard Biesheuvel wrote:
> >> On 23 February 2016 at 18:26, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> > On Tue, Feb 23, 2016 at 06:16:50PM +0100, Ard Biesheuvel wrote:
> >> >> On 23 February 2016 at 18:12, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> >> > On Mon, Feb 22, 2016 at 09:54:27PM +0100, Ard Biesheuvel wrote:
> >> >> >> --- a/arch/arm64/mm/mmu.c
> >> >> >> +++ b/arch/arm64/mm/mmu.c
> >> >> >> @@ -679,7 +679,7 @@ void __init early_fixmap_init(void)
> >> >> >>
> >> >> >>       pgd = pgd_offset_k(addr);
> >> >> >>       if (CONFIG_PGTABLE_LEVELS > 3 &&
> >> >> >> -         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
> >> >> >> +         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
> >> >> >>               /*
> >> >> >>                * We only end up here if the kernel mapping and the fixmap
> >> >> >>                * share the top level pgd entry, which should only happen on
> >> >> >
> >> >> > Do I miss any patches? The for-next/core branch has a pgd_none(*pgd)
> >> >> > check here, so this patch does not apply.
> >> >> >
> >> >>
> >> >> This is actually based on the kaslr branch, not for-next/core
> >> >>
> >> >> I'm happy to rebase and resend.
> >> >
> >> > That's fine, no need to resend. I plan to move those as well onto
> >> > for-next/core but wanted some more testing first on the initial part.
> >> >
> >> >> I have added some patches for kasan, kvm and smp as well.
> >> >
> >> > Patches related to the __pa clean-up? Or something else?
> >>
> >> No, related to the __pa restriction
> >
> > OK. I'll wait for a while before merging this series to get more reviews
> > and testing. I picked the first patch though (high_memory fix).
> 
> OK, I'll hold off for now. I have enough stuff in flight as it is.
> However, I suppose that you will want to address the performance
> concern at some point

Yes, though we first need to identify how real this concern is.
PHYS_OFFSET was a low-hanging fruit, so worth merging without additional
benchmarking.

The __pa clean-up, while nice, is relatively intrusive and would need
acks from the KVM guys as well. I wouldn't rush into merging it unless
it shows some benefits in benchmarks.

One concern I have is that we still find something in the generic code
doing a virt_to_phys() on kernel image addresses which would render all
this clean-up unnecessary (since most of the changes are not on the
critical path, we do them just to simplify virt_to_phys()).

> If anyone wants to do any benchmarking:
> git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-pa-linear-mapping

Thanks. We'll give this a try in the next few days.

-- 
Catalin