Re: Question regarding the kexec support for FSL Book E

Re: Question regarding the kexec support for FSL Book E

[Sebastian Andrzej Siewior]

Suzuki Poulose wrote:
> Hi Sebastian,
Hi,

> 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.
> 
> 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.

> Q2: Does the relocate kernel also get loaded within the 0-2GB memory ? 

Yes. We don't have a mapping >2GiB.

> 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.

> Thanks
> Suzuki Poulose
> Linux Technology Center
> IBM India

Sebastian

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

Re: Question regarding the kexec support for FSL Book E

[Suzuki Poulose]

Thanks a lot for the response. Please

On 04/07/11 13:53, Sebastian Andrzej Siewior wrote:
> Suzuki Poulose wrote:
>> Hi Sebastian,
> Hi,
>
>> 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.
>>
>> 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.
>
>> 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 ?
> Yes. We don't have a mapping >2GiB.
>

>> 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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Question regarding the kexec support for FSL Book E

[McClintock Matthew-B29882]

On Thu, Apr 7, 2011 at 6:08 AM, Suzuki Poulose <suzuki@in.ibm.com> wrote:
> 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()" ?

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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Question regarding the kexec support for FSL Book E

[Sebastian Andrzej Siewior]

* McClintock Matthew-B29882 | 2011-04-07 15:19:12 [+0000]:

>On Thu, Apr 7, 2011 at 6:08 AM, Suzuki Poulose <suzuki@in.ibm.com> wrote:
>> 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.

>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.

>
>-M

Sebastian

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

Re: Question regarding the kexec support for FSL Book E

[Suzuki Poulose]

On 04/07/11 21:52, Sebastian Andrzej Siewior wrote:
> * McClintock Matthew-B29882 | 2011-04-07 15:19:12 [+0000]:
>
>> On Thu, Apr 7, 2011 at 6:08 AM, Suzuki Poulose<suzuki@in.ibm.com>  wrote:
>>> 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.

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.

>
>> 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.
Right. If the page allocated is above 2GiB Physical Address, it is discarded,
and we look for new page.

Thanks

Suzuki

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