* Kexec query about what makes sure control pages/page tables are not overwritten
@ 2013-11-11 20:53 ` Vivek Goyal
0 siblings, 0 replies; 6+ messages in thread
From: Vivek Goyal @ 2013-11-11 20:53 UTC (permalink / raw)
To: linux kernel mailing list, Kexec Mailing List, Eric W. Biederman,
Yinghai Lu, H. Peter Anvin
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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Kexec query about what makes sure control pages/page tables are not overwritten
@ 2013-11-11 20:53 ` Vivek Goyal
0 siblings, 0 replies; 6+ messages in thread
From: Vivek Goyal @ 2013-11-11 20:53 UTC (permalink / raw)
To: linux kernel mailing list, Kexec Mailing List, Eric W. Biederman,
Yinghai Lu, H. Peter Anvin
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kexec query about what makes sure control pages/page tables are not overwritten
2013-11-11 20:53 ` Vivek Goyal
@ 2013-11-11 20:57 ` H. Peter Anvin
-1 siblings, 0 replies; 6+ messages in thread
From: H. Peter Anvin @ 2013-11-11 20:57 UTC (permalink / raw)
To: Vivek Goyal, linux kernel mailing list, Kexec Mailing List,
Eric W. Biederman, Yinghai Lu
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.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kexec query about what makes sure control pages/page tables are not overwritten
@ 2013-11-11 20:57 ` H. Peter Anvin
0 siblings, 0 replies; 6+ messages in thread
From: H. Peter Anvin @ 2013-11-11 20:57 UTC (permalink / raw)
To: Vivek Goyal, linux kernel mailing list, Kexec Mailing List,
Eric W. Biederman, Yinghai Lu
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kexec query about what makes sure control pages/page tables are not overwritten
2013-11-11 20:57 ` H. Peter Anvin
@ 2013-11-11 21:14 ` Vivek Goyal
-1 siblings, 0 replies; 6+ messages in thread
From: Vivek Goyal @ 2013-11-11 21:14 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Yinghai Lu, Kexec Mailing List, linux kernel mailing list,
Eric W. Biederman
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.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Kexec query about what makes sure control pages/page tables are not overwritten
@ 2013-11-11 21:14 ` Vivek Goyal
0 siblings, 0 replies; 6+ messages in thread
From: Vivek Goyal @ 2013-11-11 21:14 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux kernel mailing list, Kexec Mailing List, Eric W. Biederman,
Yinghai Lu
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-11-11 21:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-11 20:53 Kexec query about what makes sure control pages/page tables are not overwritten Vivek Goyal
2013-11-11 20:53 ` Vivek Goyal
2013-11-11 20:57 ` H. Peter Anvin
2013-11-11 20:57 ` H. Peter Anvin
2013-11-11 21:14 ` Vivek Goyal
2013-11-11 21:14 ` Vivek Goyal
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.