Kexec query about what makes sure control pages/page tables are not overwritten

Kexec query about what makes sure control pages/page tables are not overwritten

[Vivek Goyal]

Hi,

I am staring at control page allocation logic in case of kdump and
wondering what makes sure that these pages are not overwritten by 
next kernel.

I see that for 64bit entry, control pages have the page tables needed
for second kernel. In case of crash these pages from from crash kernel
reserved region. Page allocator is very simple and that is start from
lowest crash reserved range and move higher and allocate first available
page which is not allocated to segments. What makes sure that these pages
are not overwritten by second kernel.

I guess it becomes a general bootloader question. How do we make sure
bootloader prepared page tables/gdt will not be overwritten by kernel
(till kernel sets up its own page tables and gdt) and how should we do the
allocation and placement.

Thanks
Vivek

Re: Kexec query about what makes sure control pages/page tables are not overwritten

[H. Peter Anvin]

It is pretty simple: the kernel exports how much text+data+bss+brk it needs, and the kernel cannot use memory outside that region until it is ready to control the address space itself.

Vivek Goyal <vgoyal@redhat.com> wrote:
>Hi,
>
>I am staring at control page allocation logic in case of kdump and
>wondering what makes sure that these pages are not overwritten by 
>next kernel.
>
>I see that for 64bit entry, control pages have the page tables needed
>for second kernel. In case of crash these pages from from crash kernel
>reserved region. Page allocator is very simple and that is start from
>lowest crash reserved range and move higher and allocate first
>available
>page which is not allocated to segments. What makes sure that these
>pages
>are not overwritten by second kernel.
>
>I guess it becomes a general bootloader question. How do we make sure
>bootloader prepared page tables/gdt will not be overwritten by kernel
>(till kernel sets up its own page tables and gdt) and how should we do
>the
>allocation and placement.
>
>Thanks
>Vivek

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: Kexec query about what makes sure control pages/page tables are not overwritten

[Vivek Goyal]

On Mon, Nov 11, 2013 at 12:57:12PM -0800, H. Peter Anvin wrote:
> It is pretty simple: the kernel exports how much text+data+bss+brk it needs, and the kernel cannot use memory outside that region until it is ready to control the address space itself.

Ok. So looks like that field is.

0260/4  2.10+   init_size       Linear memory required during initialization

This helps. Thanks.

Vivek

>
 
> Vivek Goyal <vgoyal@redhat.com> wrote:
> >Hi,
> >
> >I am staring at control page allocation logic in case of kdump and
> >wondering what makes sure that these pages are not overwritten by 
> >next kernel.
> >
> >I see that for 64bit entry, control pages have the page tables needed
> >for second kernel. In case of crash these pages from from crash kernel
> >reserved region. Page allocator is very simple and that is start from
> >lowest crash reserved range and move higher and allocate first
> >available
> >page which is not allocated to segments. What makes sure that these
> >pages
> >are not overwritten by second kernel.
> >
> >I guess it becomes a general bootloader question. How do we make sure
> >bootloader prepared page tables/gdt will not be overwritten by kernel
> >(till kernel sets up its own page tables and gdt) and how should we do
> >the
> >allocation and placement.
> >
> >Thanks
> >Vivek
> 
> -- 
> Sent from my mobile phone.  Please pardon brevity and lack of formatting.