[RFC PATCH 0/2] Avoid booting stall caused by idmap_kpti_install_ng_mappings

[Justin He]

Hi Marc

> -----Original Message-----
> From: Marc Zyngier <maz at kernel.org>
> Sent: Wednesday, January 20, 2021 6:58 PM
> To: Justin He <Justin.He at arm.com>
> Cc: Catalin Marinas <Catalin.Marinas at arm.com>; Will Deacon
> <will at kernel.org>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; Anshuman Khandual <Anshuman.Khandual at arm.com>;
> Suzuki Poulose <Suzuki.Poulose at arm.com>; Mark Rutland
> <Mark.Rutland at arm.com>; Gustavo A. R. Silva <gustavoars at kernel.org>;
> Richard Henderson <richard.henderson at linaro.org>; Dave P Martin
> <Dave.Martin at arm.com>; Steven Price <Steven.Price at arm.com>; Andrew Morton
> <akpm at linux-foundation.org>; Mike Rapoport <rppt at kernel.org>; Ard
> Biesheuvel <ardb at kernel.org>; Gavin Shan <gshan at redhat.com>; Kefeng Wang
> <wangkefeng.wang at huawei.com>; Mark Brown <broonie at kernel.org>; Cristian
> Marussi <Cristian.Marussi at arm.com>
> Subject: Re: [RFC PATCH 0/2] Avoid booting stall caused by
> idmap_kpti_install_ng_mappings
> 
> Hi Justin,
> 
> On 2021-01-20 04:51, Justin He wrote:
> > Hi,
> > Kindly ping 😊
> >
> >> -----Original Message-----
> >> From: Jia He <justin.he at arm.com>
> >> Sent: Wednesday, January 13, 2021 9:41 AM
> >> To: Catalin Marinas <Catalin.Marinas at arm.com>; Will Deacon
> >> <will at kernel.org>; linux-arm-kernel at lists.infradead.org; linux-
> >> kernel at vger.kernel.org
> >> Cc: Anshuman Khandual <Anshuman.Khandual at arm.com>; Suzuki Poulose
> >> <Suzuki.Poulose at arm.com>; Justin He <Justin.He at arm.com>; Mark Rutland
> >> <Mark.Rutland at arm.com>; Gustavo A. R. Silva <gustavoars at kernel.org>;
> >> Richard Henderson <richard.henderson at linaro.org>; Dave P Martin
> >> <Dave.Martin at arm.com>; Steven Price <Steven.Price at arm.com>; Andrew
> >> Morton
> >> <akpm at linux-foundation.org>; Mike Rapoport <rppt at kernel.org>; Ard
> >> Biesheuvel <ardb at kernel.org>; Gavin Shan <gshan at redhat.com>; Kefeng
> >> Wang
> >> <wangkefeng.wang at huawei.com>; Mark Brown <broonie at kernel.org>; Marc
> >> Zyngier
> >> <maz at kernel.org>; Cristian Marussi <Cristian.Marussi at arm.com>
> >> Subject: [RFC PATCH 0/2] Avoid booting stall caused by
> >>
> >> There is a 10s stall in idmap_kpti_install_ng_mappings when kernel
> >> boots
> >> on a Ampere EMAG server.
> >>
> >> Commit f992b4dfd58b ("arm64: kpti: Add ->enable callback to remap
> >> swapper using nG mappings") updates the nG bit runtime if kpti is
> >> required.
> >>
> >> But things get worse if rodata=full in map_mem(). NO_BLOCK_MAPPINGS |
> >> NO_CONT_MAPPINGS is required when creating pagetable mapping. Hence
> >> all
> >> ptes are fully mapped in this case. On a Ampere EMAG server with 256G
> >> memory(pagesize=4k), it causes the 10s stall.
> >>
> >> After moving init_cpu_features() ahead of early_fixmap_init(), we can
> >> use
> >> cpu_have_const_cap earlier than before. Hence we can avoid this stall
> >> by updating arm64_use_ng_mappings.
> >>
> >> After this patch series, it reduces the kernel boot time from 14.7s to
> >> 4.1s:
> >> Before:
> >> [   14.757569] Freeing initrd memory: 60752K
> >> After:
> >> [    4.138819] Freeing initrd memory: 60752K
> >>
> >> Set it as RFC because I want to resolve any other points which I have
> >> misconerned.
> 
> But you don't really explain *why* having the CPU Feature discovery
> early helps at all. Is that so that you can bypass the idmap mapping?

Adding nG bits can be avoided by having the discovery of boot cpu feature
earlier since the nG bit had been set in PTE_MAYBE_NG/PMD_MAYBE_NG 

Before this patch:
1. kernel will firstly create mapping in setup_arch->paging_init->map_mem
-> __map_memblock
2. Then if kpti is required, kernel will add nG bits for each pte entry.
3. In extreme case, e.g. physical memory is 256G,rodata=full, and pagesize
is 4K, the nG bits updating in step 2 takes about 10s.

> I'd expect something that explain the problem instead of paraphrasing
> the patches.
> 
> Another thing is whether you have tested this on some ThunderX HW

I will find a TX1 as you told to see any difference.


--
Cheers,
Justin (Jia He)


> (the first version, not TX2), as this is the whole reason for this
> code...
> 
> Thanks,
> 
>          M.
> --
> Jazz is not dead. It just smells funny...