How does kdump deal with trampoline allocation?

How does kdump deal with trampoline allocation?

[H. Peter Anvin]

Hi guys,

I'm planning a major overhaul of the trampoline allocation in x86, and
I'm trying to understand how kdump deals with it.  The trampoline has to
be allocated in low memory (< 1 MiB) and obviously that doesn't include
the kdump area at all.

	-hpa

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: How does kdump deal with trampoline allocation?

[Vivek Goyal]

On Mon, Dec 27, 2010 at 12:31:20PM -0800, H. Peter Anvin wrote:
> Hi guys,
> 
> I'm planning a major overhaul of the trampoline allocation in x86, and
> I'm trying to understand how kdump deals with it.  The trampoline has to
> be allocated in low memory (< 1 MiB) and obviously that doesn't include
> the kdump area at all.

Hi Peter,

Kdump has the concept of backup area. We backup the contents of first
640KB of physical RAM in kdump reserved area and then allow kdump kernel
to use first 640KB of memory. So any trampoline allocation can be done
in low memory area without overwritting the contents of first kernel.

Thanks
Vivek 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: How does kdump deal with trampoline allocation?

[H. Peter Anvin]

On 12/27/2010 04:06 PM, Vivek Goyal wrote:
> On Mon, Dec 27, 2010 at 12:31:20PM -0800, H. Peter Anvin wrote:
>> Hi guys,
>>
>> I'm planning a major overhaul of the trampoline allocation in x86, and
>> I'm trying to understand how kdump deals with it.  The trampoline has to
>> be allocated in low memory (< 1 MiB) and obviously that doesn't include
>> the kdump area at all.
> 
> Hi Peter,
> 
> Kdump has the concept of backup area. We backup the contents of first
> 640KB of physical RAM in kdump reserved area and then allow kdump kernel
> to use first 640KB of memory. So any trampoline allocation can be done
> in low memory area without overwritting the contents of first kernel.
> 

OK, that's straightforward.  That presumably means that the low 640K is
marked unused in the memory map that memblock sees during early startup.
 That fits very cleanly with the patches I'm doing.

Thanks!

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: How does kdump deal with trampoline allocation?

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> On 12/27/2010 04:06 PM, Vivek Goyal wrote:
>> On Mon, Dec 27, 2010 at 12:31:20PM -0800, H. Peter Anvin wrote:
>>> Hi guys,
>>>
>>> I'm planning a major overhaul of the trampoline allocation in x86, and
>>> I'm trying to understand how kdump deals with it.  The trampoline has to
>>> be allocated in low memory (< 1 MiB) and obviously that doesn't include
>>> the kdump area at all.
>> 
>> Hi Peter,
>> 
>> Kdump has the concept of backup area. We backup the contents of first
>> 640KB of physical RAM in kdump reserved area and then allow kdump kernel
>> to use first 640KB of memory. So any trampoline allocation can be done
>> in low memory area without overwritting the contents of first kernel.
>> 
>
> OK, that's straightforward.  That presumably means that the low 640K is
> marked unused in the memory map that memblock sees during early startup.
>  That fits very cleanly with the patches I'm doing.

Additionally we typically start with maxcpus=1 so we don't strictly
need the trampoline to start other cpus.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: How does kdump deal with trampoline allocation?

[H. Peter Anvin]

On 12/27/2010 11:40 PM, Eric W. Biederman wrote:
>>
>> OK, that's straightforward.  That presumably means that the low 640K is
>> marked unused in the memory map that memblock sees during early startup.
>>  That fits very cleanly with the patches I'm doing.
> 
> Additionally we typically start with maxcpus=1 so we don't strictly
> need the trampoline to start other cpus.
> 

Well, the trampoline is optional only on 32 bits, and with my changes,
it would be unconditional.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: How does kdump deal with trampoline allocation?

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> On 12/27/2010 11:40 PM, Eric W. Biederman wrote:
>>>
>>> OK, that's straightforward.  That presumably means that the low 640K is
>>> marked unused in the memory map that memblock sees during early startup.
>>>  That fits very cleanly with the patches I'm doing.
>> 
>> Additionally we typically start with maxcpus=1 so we don't strictly
>> need the trampoline to start other cpus.
>> 
>
> Well, the trampoline is optional only on 32 bits, and with my changes,
> it would be unconditional.

What motivates your trampoline rewrite?

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: How does kdump deal with trampoline allocation?

[H. Peter Anvin]

On 12/28/2010 08:13 PM, Eric W. Biederman wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>>
>> Well, the trampoline is optional only on 32 bits, and with my changes,
>> it would be unconditional.
> 
> What motivates your trampoline rewrite?
> 

The fact that so far four different pieces of code have low memory
trampolines, and each is implemented differently.  Furthermore, I'm
currently being forced to work on a fifth.  This unifies all that code,
but it also makes it unconditional since at least reboot=bios is always
going to need to be there.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: How does kdump deal with trampoline allocation?

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> On 12/28/2010 08:13 PM, Eric W. Biederman wrote:
>> "H. Peter Anvin" <hpa@zytor.com> writes:
>>>
>>> Well, the trampoline is optional only on 32 bits, and with my changes,
>>> it would be unconditional.
>> 
>> What motivates your trampoline rewrite?
>> 
>
> The fact that so far four different pieces of code have low memory
> trampolines, and each is implemented differently.  Furthermore, I'm
> currently being forced to work on a fifth.  This unifies all that code,
> but it also makes it unconditional since at least reboot=bios is always
> going to need to be there.

That makes some sense.  I remember seeing your complaining about how
many different flavors of physical page tables we have.

When your patches are ready cc me and I will be happy to look them
over and see if I can spot anything you might have missed.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: How does kdump deal with trampoline allocation?

[Vivek Goyal]

On Mon, Dec 27, 2010 at 04:13:55PM -0800, H. Peter Anvin wrote:
> On 12/27/2010 04:06 PM, Vivek Goyal wrote:
> > On Mon, Dec 27, 2010 at 12:31:20PM -0800, H. Peter Anvin wrote:
> >> Hi guys,
> >>
> >> I'm planning a major overhaul of the trampoline allocation in x86, and
> >> I'm trying to understand how kdump deals with it.  The trampoline has to
> >> be allocated in low memory (< 1 MiB) and obviously that doesn't include
> >> the kdump area at all.
> > 
> > Hi Peter,
> > 
> > Kdump has the concept of backup area. We backup the contents of first
> > 640KB of physical RAM in kdump reserved area and then allow kdump kernel
> > to use first 640KB of memory. So any trampoline allocation can be done
> > in low memory area without overwritting the contents of first kernel.
> > 
> 
> OK, that's straightforward.  That presumably means that the low 640K is
> marked unused in the memory map that memblock sees during early startup.

Yes, the available memory for second kernel is told to second kernel with
kernel command line option "memmap=", hence it should be visible to 
memblock and it should be able to allocate this memory.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec