* Xunlei Pang <[email protected]> wrote:
> On 05/05/2017 at 05:20 PM, Ingo Molnar wrote:
> > * Xunlei Pang <[email protected]> wrote:
> >
> >> On 05/05/2017 at 02:52 PM, Ingo Molnar wrote:
> >>> * Xunlei Pang <[email protected]> wrote:
> >>>
> >>>> @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image,
> >>>> unsigned long start_pgtable)
> >>>>
> >>>> level4p = (pgd_t *)__va(start_pgtable);
> >>>> clear_page(level4p);
> >>>> +
> >>>> + if (direct_gbpages)
> >>>> + info.direct_gbpages = true;
> >>> No, this should be keyed off the CPU feature (X86_FEATURE_GBPAGES)
> >>> automatically,
> >>> not set blindly! AFAICS this patch will crash kexec on any CPU that does
> >>> not
> >>> support gbpages.
> >> It should be fine, probe_page_size_mask() already takes care of this:
> >> if (direct_gbpages && boot_cpu_has(X86_FEATURE_GBPAGES)) {
> >> printk(KERN_INFO "Using GB pages for direct mapping\n");
> >> page_size_mask |= 1 << PG_LEVEL_1G;
> >> } else {
> >> direct_gbpages = 0;
> >> }
> >>
> >> So if X86_FEATURE_GBPAGES is not supported, direct_gbpages will be set to
> >> 0.
> > So why is the introduction of the info.direct_gbpages flag necessary?
> > AFAICS it
> > just duplicates the kernel's direct_gbpages flag. One outcome is that
> > hibernation
> > won't use gbpages, which is silly.
>
> boot/compressed/pagetable.c also uses kernel_ident_mapping_init() for kaslr,
> at
> the moment we don't have "direct_gbpages" definition or X86_FEATURE_GBPAGES
> feature detection.
>
> I thought that we can change the other call sites when found really needed.
Ok, you are right - I'll use the original patches as submitted, with the
updated
changelogs.
Thanks,
Ingo
