How does kdump deal with trampoline allocation?
Subsystems (2)
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
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 6 lines · 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.
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
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 8 lines · Vivek Goyal
Quoted 6 lines · 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.
Quoted 7 lines
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
Signature · 8 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Quoted 17 lines · H. Peter Anvin
Quoted 8 lines · Vivek Goyal
Quoted 6 lines · 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.
Quoted 7 lines
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.
Quoted 3 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 8 lines · Eric W. Biederman
Quoted 4 lines
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
Signature · 8 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Quoted 6 lines · H. Peter Anvin
Quoted 5 lines · Eric W. Biederman
Quoted 4 lines
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.
Quoted 6 lines
Quoted 3 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 7 lines · Eric W. Biederman
Quoted 3 lines · H. Peter Anvin
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
Signature · 8 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
Quoted 6 lines · H. Peter Anvin
Quoted 5 lines · Eric W. Biederman
Quoted 3 lines · H. Peter Anvin
Well, the trampoline is optional only on 32 bits, and with my changes, it would be unconditional.
Quoted 8 lines
Quoted 2 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 11 lines · H. Peter Anvin
Quoted 10 lines · Vivek Goyal
Quoted 6 lines · 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.
Hi Peter,
Quoted 8 lines
Quoted 5 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec