[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171110091453.6pk5lotvom2cf4mv@gmail.com>
Date: Fri, 10 Nov 2017 10:14:53 +0100
From: Ingo Molnar <mingo@...nel.org>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Ingo Molnar <mingo@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...capital.net>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
Borislav Petkov <bp@...e.de>, Andi Kleen <ak@...ux.intel.com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] x86/boot/compressed/64: Introduce place_trampoline()
* Kirill A. Shutemov <kirill.shutemov@...ux.intel.com> wrote:
> If bootloader enables 64-bit mode with 4-level paging, we need to
> switch over to 5-level paging. The switching requires disabling paging.
> It works fine if kernel itself is loaded below 4G.
>
> If bootloader put the kernel above 4G (not sure if anybody does this),
> we would loose control as soon as paging is disabled as code becomes
> unreachable.
>
> To handle the situation, we need a trampoline in lower memory that would
> take care about switching on 5-level paging.
>
> Apart from trampoline itself we also need place to store top level page
> table in lower memory as we don't have a way to load 64-bit value into
> CR3 from 32-bit mode. We only really need 8-bytes there as we only use
> the very first entry of the page table. But we allocate whole page
> anyway. We cannot have the code in the same because, there's hazard that
> a CPU would read page table speculatively and get confused seeing
> garbage.
>
> This patch introduces place_trampoline() that finds right spot in lower
> memory for trampoline, copies trampoline code there and setups new top
> level page table for 5-level paging.
>
> At this point we do all the preparation, but not yet use trampoline.
> It will be done in following patch.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> ---
> arch/x86/boot/compressed/head_64.S | 13 +++++++++++
> arch/x86/boot/compressed/pagetable.c | 42 ++++++++++++++++++++++++++++++++++++
> arch/x86/boot/compressed/pagetable.h | 18 ++++++++++++++++
> 3 files changed, 73 insertions(+)
> create mode 100644 arch/x86/boot/compressed/pagetable.h
Ok, I like it how almost all of the complexity is now at the .c level.
I'm wondering, how did you test it if no current bootloader puts the kernel to
above addresses of 4G?
Thanks,
Ingo
Powered by blists - more mailing lists