[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170527224624.opc4yg4m7irvwbjl@node.shutemov.name>
Date: Sun, 28 May 2017 01:46:24 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Brian Gerst <brgerst@...il.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
the arch/x86 maintainers <x86@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>,
Dave Hansen <dave.hansen@...el.com>,
Andy Lutomirski <luto@...capital.net>,
linux-arch <linux-arch@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv1, RFC 5/8] x86/mm: Fold p4d page table layer at runtime
On Sat, May 27, 2017 at 11:09:54AM -0400, Brian Gerst wrote:
> > static inline int pgd_none(pgd_t pgd)
> > {
> > + if (p4d_folded)
> > + return 0;
> > /*
> > * There is no need to do a workaround for the KNL stray
> > * A/D bit erratum here. PGDs only point to page tables
>
> These should use static_cpu_has(X86_FEATURE_LA57), so that it gets
> patched by alternatives.
Right, eventually we would likely need something like this. But at this
point I'm more worried about correctness than performance. Performance
will be the next step.
And I haven't tried it yet, but I would expect direct use of alternatives
wouldn't be possible. If I read code correctly, we enable paging way
before we apply alternatives. But we need to have something functional in
between.
I guess it will be fun :)
--
Kirill A. Shutemov
Powered by blists - more mailing lists