Question regarding the kexec support for FSL Book E
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line · Suzuki Poulose
Hi Sebastian,
Hi,
Quoted 5 lines
I am working on the Kexec support for PPC44x based boards. I was going through the patchset that you have posted for FSL Book E. I was not able to understand some parts of the setup code. If you have some time, could you please help me by answering the questions below :
Quoted 8 lines
Here is what I understood from the code walk through :
In
relocate_kernel:, we try to setup a 1:1 mapping for 0-2GB of memory so that the code could run with the MMU switched on. We leave a temparory mapping in place and create the mapping for 0-2GiB.Q1: Does the temparory mapping cover the code which sets up the mapping ? i.e, the code in
fsl_booke_entry_mapping.S?
Yes, it does. Please keep in mind that relocate_new_kernel is kmalloc() into a separate page while running. This is not just the case for FSL-BookE but for all arches.
Quoted 1 line
Q2: Does the relocate kernel also get loaded within the 0-2GB memory ?
Yes. We don't have a mapping >2GiB.
Quoted 3 lines
If so,
won't we have multiple mappings for the code we are executing, unless we were mapped 1:1 by the primary kernel ?
The primary kernel maps 0-2GiB 1:1. We jump to relocate_new_kernel() which is somewhere within 0..2GiB and not part of the original kernel image. This code has a page list of the new kernel. It copies the new kernel to its final position and overwrites the old kernel. This is not a problem as you remember relocate_new_kernel() is no longer part of the old image.
Once the image is copied, we jump to purgatory and then to the new kernel.
Quoted 4 lines
Thanks
Suzuki Poulose
Linux Technology Center
IBM India
Sebastian
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Thanks a lot for the response. Please
Quoted 15 lines · Sebastian Andrzej Siewior
Quoted 1 line · Suzuki Poulose
Hi Sebastian,
Hi,
Quoted 11 lines
I am working on the Kexec support for PPC44x based boards. I was going through the patchset that you have posted for FSL Book E. I was not able to understand some parts of the setup code. If you have some time, could you please help me by answering the questions below :
Here is what I understood from the code walk through :
In
relocate_kernel:, we try to setup a 1:1 mapping for 0-2GB of memory so that the code could run with the MMU switched on. We leave a temparory mapping in place and create the mapping for 0-2GiB.
Quoted 9 lines
Quoted 2 lines
Q1: Does the temparory mapping cover the code which sets up the mapping ? i.e, the code in
fsl_booke_entry_mapping.S?Yes, it does. Please keep in mind that
relocate_new_kerneliskmalloc()into a separate page while running. This is not just the case for FSL-BookE but for all arches.Quoted 1 line
Q2: Does the relocate kernel also get loaded within the 0-2GB memory ?
The above should have been relocate_new_kernel(), loaded into 0-2GB virtual address ?
Quoted 9 lines
Yes. We don't have a mapping >2GiB.
Quoted 3 lines
If so,
won't we have multiple mappings for the code we are executing, unless we were mapped 1:1 by the primary kernel ?The primary kernel maps 0-2GiB 1:1. We jump to
relocate_new_kernel()which is somewhere within 0..2GiB and not part of the original kernel image.
So the 0-2GiB 1:1 mapping, could create a 1:1 entry for the relocate_new_kernel()'s physical address(which is again somewhere in 0..2GiB) too. But the virtual address for relocate_new_kernel() could be different (not necessarily 1:1, as mapped by the primary kernel). So we will have one mapping setup by the primary kernel and the other by the 1:1 mapping.
This is the case of "multiple mappings", I was referring to above.
How is this case taken care of ? Is it via the temporary mapping ? What is the virtual
address used by temporary mapping for the "relocate_new_kernel()" ?
Thanks
Suzuki
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 9 lines · Suzuki Poulose
So the 0-2GiB 1:1 mapping, could create a 1:1 entry for the relocate_new_kernel()'s physical address(which is again somewhere in 0..2GiB) too.
But the virtual address forrelocate_new_kernel()could be different (not necessarily 1:1, as mapped by the primary kernel). So we will have one mapping setup
by the primary kernel and the other by the 1:1 mapping.
This is the case of "multiple mappings", I was referring to above.
Quoted 3 lines
How is this case taken care of ? Is it via the temporary mapping ? What is the virtual
address used by temporary mapping for the "relocate_new_kernel()" ?
When you load the new kexec image with kexec -l, I believe we make sure we are in the first 2gb of memory. Then when you kexec, all the TLB's are torn down and we setup a 1:1 virtual:physical mapping for the first 2GB of memory. Then some assembly copies kernel from the stored location to the destination and we boot the new kernel.
-M
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 4 lines · * McClintock Matthew-B29882 | 2011-04-07 15:19:12 [+0000]:
Quoted 3 lines · Suzuki Poulose
How is this case taken care of ? Is it via the temporary mapping ? What is the virtual
address used by temporary mapping for the "relocate_new_kernel()" ?
It is the same as the physical :) It is hard to tell where exactly the kernel image will be. It is somewhere between 0 and KEXEC_CONTROL_MEMORY_LIMIT. It is allocated in kimage_alloc_normal_control_pages(). It should not matter where it is.
Quoted 5 lines
When you load the new kexec image with kexec -l, I believe we make sure we are in the first 2gb of memory. Then when you kexec, all the TLB's are torn down and we setup a 1:1 virtual:physical mapping for the first 2GB of memory. Then some assembly copies kernel from the stored location to the destination and we boot the new kernel.
arch/powerpc/include/asm/kexec.h:
|#ifdef CONFIG_FSL_BOOKE | |/* | * On FSL-BookE we setup a 1:1 mapping which covers the first 2GiB of memory | * and therefore we can only deal with memory within this range | */ |#define KEXEC_SOURCE_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1) |#define KEXEC_DESTINATION_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1) |#define KEXEC_CONTROL_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1) | |#else
So the kernel never gives memory above 2GiB to userland.
Quoted 2 lines
-M
Sebastian
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 11 lines · Sebastian Andrzej Siewior
Quoted 4 lines · * McClintock Matthew-B29882 | 2011-04-07 15:19:12 [+0000]:
Quoted 3 lines · Suzuki Poulose
How is this case taken care of ? Is it via the temporary mapping ? What is the virtual
address used by temporary mapping for the "relocate_new_kernel()" ?It is the same as the physical :) It is hard to tell where exactly the kernel image will be. It is somewhere between 0 and
KEXEC_CONTROL_MEMORY_LIMIT. It is allocated inkimage_alloc_normal_control_pages(). It should not matter where it is.
I guess I got my answer :). The virtual address of the relocate_new_kernel() is a kernel space VA, and hence would be above 2G (> PAGE_OFFSET), so there won't be a clash of the 1:1 mapping that we create. Also, the src/destination pages won't overlap the with the relocate_new_kernel. Hence we are safe.
Quoted 20 lines
Quoted 6 lines
When you load the new kexec image with kexec -l, I believe we make sure we are in the first 2gb of memory. Then when you kexec, all the TLB's are torn down and we setup a 1:1 virtual:physical mapping for the first 2GB of memory. Then some assembly copies kernel from the stored location to the destination and we boot the new kernel.
arch/powerpc/include/asm/kexec.h:|#ifdef CONFIG_FSL_BOOKE | |/* | * On FSL-BookE we setup a 1:1 mapping which covers the first 2GiB of memory | * and therefore we can only deal with memory within this range | */ |#define KEXEC_SOURCE_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1) |#define KEXEC_DESTINATION_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1) |#define KEXEC_CONTROL_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1) | |#else
Quoted 1 line
So the kernel never gives memory above 2GiB to userland.
Right. If the page allocated is above 2GiB Physical Address, it is discarded, and we look for new page.
Thanks
Suzuki
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec