* How does kdump deal with trampoline allocation?
@ 2010-12-27 20:31 H. Peter Anvin
2010-12-28 0:06 ` Vivek Goyal
0 siblings, 1 reply; 9+ messages in thread
From: H. Peter Anvin @ 2010-12-27 20:31 UTC (permalink / raw)
To: kexec@lists.infradead.org, Vivek Goyal, Yinghai Lu; +Cc: Eric W. Biederman
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How does kdump deal with trampoline allocation?
2010-12-27 20:31 How does kdump deal with trampoline allocation? H. Peter Anvin
@ 2010-12-28 0:06 ` Vivek Goyal
2010-12-28 0:13 ` H. Peter Anvin
0 siblings, 1 reply; 9+ messages in thread
From: Vivek Goyal @ 2010-12-28 0:06 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Yinghai Lu, kexec@lists.infradead.org, Eric W. Biederman
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How does kdump deal with trampoline allocation?
2010-12-28 0:06 ` Vivek Goyal
@ 2010-12-28 0:13 ` H. Peter Anvin
2010-12-28 7:40 ` Eric W. Biederman
2011-01-03 5:01 ` Vivek Goyal
0 siblings, 2 replies; 9+ messages in thread
From: H. Peter Anvin @ 2010-12-28 0:13 UTC (permalink / raw)
To: Vivek Goyal; +Cc: Yinghai Lu, kexec@lists.infradead.org, Eric W. Biederman
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How does kdump deal with trampoline allocation?
2010-12-28 0:13 ` H. Peter Anvin
@ 2010-12-28 7:40 ` Eric W. Biederman
2010-12-28 20:11 ` H. Peter Anvin
2011-01-03 5:01 ` Vivek Goyal
1 sibling, 1 reply; 9+ messages in thread
From: Eric W. Biederman @ 2010-12-28 7:40 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Yinghai Lu, kexec@lists.infradead.org, Vivek Goyal
"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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How does kdump deal with trampoline allocation?
2010-12-28 7:40 ` Eric W. Biederman
@ 2010-12-28 20:11 ` H. Peter Anvin
2010-12-29 4:13 ` Eric W. Biederman
0 siblings, 1 reply; 9+ messages in thread
From: H. Peter Anvin @ 2010-12-28 20:11 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Yinghai Lu, kexec@lists.infradead.org, Vivek Goyal
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How does kdump deal with trampoline allocation?
2010-12-28 20:11 ` H. Peter Anvin
@ 2010-12-29 4:13 ` Eric W. Biederman
2010-12-29 6:25 ` H. Peter Anvin
0 siblings, 1 reply; 9+ messages in thread
From: Eric W. Biederman @ 2010-12-29 4:13 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Yinghai Lu, kexec@lists.infradead.org, Vivek Goyal
"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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How does kdump deal with trampoline allocation?
2010-12-29 4:13 ` Eric W. Biederman
@ 2010-12-29 6:25 ` H. Peter Anvin
2010-12-29 8:37 ` Eric W. Biederman
0 siblings, 1 reply; 9+ messages in thread
From: H. Peter Anvin @ 2010-12-29 6:25 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Yinghai Lu, kexec@lists.infradead.org, Vivek Goyal
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How does kdump deal with trampoline allocation?
2010-12-29 6:25 ` H. Peter Anvin
@ 2010-12-29 8:37 ` Eric W. Biederman
0 siblings, 0 replies; 9+ messages in thread
From: Eric W. Biederman @ 2010-12-29 8:37 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Yinghai Lu, kexec@lists.infradead.org, Vivek Goyal
"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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How does kdump deal with trampoline allocation?
2010-12-28 0:13 ` H. Peter Anvin
2010-12-28 7:40 ` Eric W. Biederman
@ 2011-01-03 5:01 ` Vivek Goyal
1 sibling, 0 replies; 9+ messages in thread
From: Vivek Goyal @ 2011-01-03 5:01 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Yinghai Lu, kexec@lists.infradead.org, Eric W. Biederman
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-01-03 5:01 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-27 20:31 How does kdump deal with trampoline allocation? H. Peter Anvin
2010-12-28 0:06 ` Vivek Goyal
2010-12-28 0:13 ` H. Peter Anvin
2010-12-28 7:40 ` Eric W. Biederman
2010-12-28 20:11 ` H. Peter Anvin
2010-12-29 4:13 ` Eric W. Biederman
2010-12-29 6:25 ` H. Peter Anvin
2010-12-29 8:37 ` Eric W. Biederman
2011-01-03 5:01 ` Vivek Goyal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox