Hello Serge,
On 16/11/2020 23:31, Serge Semin wrote:
>> As completely unrelated optimization I can remove the same memblock_add() of
>> the
>> kernel sections from the Octeon platform code.
> Why not as long as it will work. AFAICS the octeon platform code does
> some kernel start address
On Fri, Nov 13, 2020 at 02:09:09PM +0100, Alexander Sverdlin wrote:
> Hello Serge, Thomas,
>
> On 13/11/2020 10:17, Alexander Sverdlin wrote:
> >> So IMHO what could be the best conclusion in the framework of this patch:
> >> 1) As Thomas said any platform-specific reservation should be done in
Hello Serge, Thomas,
On 13/11/2020 10:17, Alexander Sverdlin wrote:
>> So IMHO what could be the best conclusion in the framework of this patch:
>> 1) As Thomas said any platform-specific reservation should be done in the
>> platform-specific code. That means if octeon needs some memory behind
>>
Hi Jiaxun,
On 13/11/2020 03:30, Jiaxun Yang wrote:
>> 2) The check_kernel_sections_mem() method can be removed. But it
>> should be done carefully. We at least need to try to find all the
>> platforms, which rely on its functionality.
> It have been more than 10 years since introducing this this
Hi!
On 13/11/2020 03:30, Jiaxun Yang wrote:
>> 2) The check_kernel_sections_mem() method can be removed. But it
>> should be done carefully. We at least need to try to find all the
>> platforms, which rely on its functionality.
> It have been more than 10 years since introducing this this check,
Hello Serge, Thomas,
On 11/11/2020 15:52, Serge Semin wrote:
>>> Could you send a patch, which removes check_kernel_section_mem completly ?
finally I think you are right and this would be the right way.
>> this will expose one issue:
>> platforms usually do it in a sane way, like it was done
On Fri, 13 Nov 2020, Jinyang He wrote:
> Commit: d3ff93380232 (mips: Make sure kernel memory is in iomem)
> As I thought, this check is related to kdump. More directly, it is
> related to the "mem=" parameter. Kexec-tools provide a "mem=" parameter
> to limit the kernel location in kdump. But
Hi, Jiaxun,
On 11/13/2020 10:30 AM, Jiaxun Yang wrote:
Hi all,
在 2020/11/11 22:52, Serge Semin 写道:
Hello Alexander
On Tue, Nov 10, 2020 at 11:29:50AM +0100, Alexander Sverdlin wrote:
2) The check_kernel_sections_mem() method can be removed. But it
should be done carefully. We at least need
Hi all,
在 2020/11/11 22:52, Serge Semin 写道:
Hello Alexander
On Tue, Nov 10, 2020 at 11:29:50AM +0100, Alexander Sverdlin wrote:
2) The check_kernel_sections_mem() method can be removed. But it
should be done carefully. We at least need to try to find all the
platforms, which rely on its
Hello Alexander
On Tue, Nov 10, 2020 at 11:29:50AM +0100, Alexander Sverdlin wrote:
> Hello Thomas,
>
> On 10/11/2020 10:55, Thomas Bogendoerfer wrote:
> Linux doesn't own the memory immediately after the kernel image. On
> Octeon
> bootloader places a shared structure right
Hello Thomas,
On 10/11/2020 10:55, Thomas Bogendoerfer wrote:
Linux doesn't own the memory immediately after the kernel image. On Octeon
bootloader places a shared structure right close after the kernel _end,
refer to "struct cvmx_bootinfo *octeon_bootinfo" in
On Mon, Nov 09, 2020 at 11:34:33AM +0100, Alexander Sverdlin wrote:
> Hello Thomas,
>
> On 07/11/2020 10:40, Thomas Bogendoerfer wrote:
> >> Linux doesn't own the memory immediately after the kernel image. On Octeon
> >> bootloader places a shared structure right close after the kernel _end,
> >>
Hi Thomas,
On 09/11/2020 11:34, Alexander Sverdlin wrote:
>>> Linux doesn't own the memory immediately after the kernel image. On Octeon
>>> bootloader places a shared structure right close after the kernel _end,
>>> refer to "struct cvmx_bootinfo *octeon_bootinfo" in cavium-octeon/setup.c.
>>>
Hello Thomas,
On 07/11/2020 10:40, Thomas Bogendoerfer wrote:
>> Linux doesn't own the memory immediately after the kernel image. On Octeon
>> bootloader places a shared structure right close after the kernel _end,
>> refer to "struct cvmx_bootinfo *octeon_bootinfo" in cavium-octeon/setup.c.
>>
On Fri, Nov 06, 2020 at 03:10:01PM +0100, Alexander A Sverdlin wrote:
> From: Alexander Sverdlin
>
> Linux doesn't own the memory immediately after the kernel image. On Octeon
> bootloader places a shared structure right close after the kernel _end,
> refer to "struct cvmx_bootinfo
From: Alexander Sverdlin
Linux doesn't own the memory immediately after the kernel image. On Octeon
bootloader places a shared structure right close after the kernel _end,
refer to "struct cvmx_bootinfo *octeon_bootinfo" in cavium-octeon/setup.c.
If check_kernel_sections_mem() rounds the PFNs
16 matches
Mail list logo
