lkml.org 
[lkml]   [2017]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/4] x86/boot/compressed/64: Introduce place_trampoline()
On Fri, Nov 10, 2017 at 10:28:12AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <mingo@kernel.org> wrote:
>
> > > --- a/arch/x86/boot/compressed/head_64.S
> > > +++ b/arch/x86/boot/compressed/head_64.S
> > > @@ -315,6 +315,18 @@ ENTRY(startup_64)
> > > * The first step is go into compatibility mode.
> > > */
> > >
> > > + /*
> > > + * Find suitable place for trampoline and populate it.
> > > + * The address will be stored in RCX.
> > > + *
> > > + * RSI holds real mode data and need to be preserved across
> > > + * a function call.
> > > + */
> > > + pushq %rsi
> > > + call place_trampoline
> > > + popq %rsi
> > > + movq %rax, %rcx
> > > +
> > > /* Clear additional page table */
> > > leaq lvl5_pgtable(%rbx), %rdi
> > > xorq %rax, %rax
> >
> > One request: it's always going to be fragile if the _only_ thing that uses the
> > trampoline is the 5-level paging code.
> >
> > Could we use the trampoline in the 4-level paging case too? It's not required, but
> > would test much of the trampoline allocation and copying machinery - and the
> > performance cost is negligible.
>
> Note that right now the trampoline is pointless on 4-level setups, so there's
> nothing to copy - but we could perhaps make it meaningful. But maybe it's not a
> good idea.

Let me see how it will play out.

> One other detail I noticed:
>
> /* Bound size of trampoline code */
> .org lvl5_trampoline_src + LVL5_TRAMPOLINE_CODE_SIZE
>
> will this generate a build error if the trampoline code exceeds 0x40?

Yes, this is the point. Just a failsafe if trampoline code would grew too
much.

--
Kirill A. Shutemov

\
 
 \ /
  Last update: 2017-11-10 10:56    [W:0.056 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site