The static memory footprint of a kernel Image at boot is larger than the
Image file itself. Things like .bss data and initial page tables are allocated
statically but populated dynamically so their content is not contained in the
Image file.
However, if EFI (or GRUB) has loaded the Image at
If we cannot relocate the kernel Image to its preferred offset of base of DRAM
plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary plus
TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
proceed normally otherwise.
Signed-off-by: Ard Biesheuvel
From: Mark Rutland mark.rutl...@arm.com
In certain cases the cpu-release-addr of a CPU may not fall in the
linear mapping (e.g. when the kernel is loaded above this address due to
the presence of other images in memory). This is problematic for the
spin-table code as it assumes that it can
Resending this series sent out yesterday with only minor changes and acks etc
added.
In summary: patch #3 relaxes the requirements imposed by the EFI stub on where
Image may be loaded, but this breaks APM Mustang (if booting via UEFI) if patch
#1 does not go in first. Patch #2 prevents potential
On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
From: Mark Rutland mark.rutl...@arm.com
In certain cases the cpu-release-addr of a CPU may not fall in the
linear mapping (e.g. when the kernel is loaded above this address due to
the presence of other images in memory). This is
On 30 July 2014 13:30, Will Deacon will.dea...@arm.com wrote:
On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
From: Mark Rutland mark.rutl...@arm.com
In certain cases the cpu-release-addr of a CPU may not fall in the
linear mapping (e.g. when the kernel is loaded above this
On 30 July 2014 14:00, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 30 July 2014 13:30, Will Deacon will.dea...@arm.com wrote:
On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
From: Mark Rutland mark.rutl...@arm.com
In certain cases the cpu-release-addr of a CPU may not
On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel wrote:
On 30 July 2014 13:30, Will Deacon will.dea...@arm.com wrote:
On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
From: Mark Rutland mark.rutl...@arm.com
In certain cases the cpu-release-addr of a CPU may not fall
On Wed, Jul 30, 2014 at 01:30:29PM +0100, Mark Rutland wrote:
On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel wrote:
On 30 July 2014 13:30, Will Deacon will.dea...@arm.com wrote:
On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
From: Mark Rutland
On Wed, Jul 30, 2014 at 01:42:58PM +0100, Will Deacon wrote:
On Wed, Jul 30, 2014 at 01:30:29PM +0100, Mark Rutland wrote:
On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel wrote:
On 30 July 2014 13:30, Will Deacon will.dea...@arm.com wrote:
On Wed, Jul 30, 2014 at 11:59:02AM
On 30 July 2014 14:49, Mark Rutland mark.rutl...@arm.com wrote:
On Wed, Jul 30, 2014 at 01:42:58PM +0100, Will Deacon wrote:
On Wed, Jul 30, 2014 at 01:30:29PM +0100, Mark Rutland wrote:
On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel wrote:
On 30 July 2014 13:30, Will Deacon
On 30 July 2014 15:10, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 30 July 2014 14:49, Mark Rutland mark.rutl...@arm.com wrote:
On Wed, Jul 30, 2014 at 01:42:58PM +0100, Will Deacon wrote:
On Wed, Jul 30, 2014 at 01:30:29PM +0100, Mark Rutland wrote:
On Wed, Jul 30, 2014 at 01:00:40PM
On Mon, Jul 28, 2014 at 02:21:53PM +0100, Michael Brown wrote:
commit c7fb93ec51d462ec3540a729ba446663c26a0505 upstream
Thanks, I'll use this backport for the 3.11 kernel as well.
Cheers,
--
Luís
The PE/COFF headers currently describe only the initialised-data
portions of the image, and
On Mon, 21 Jul, at 05:16:19PM, Ard Biesheuvel wrote:
Similar to how text offset and kernel size are mangled to produce little
endian constants for the Image header regardless of the endianness of the
kernel, this adds a number of constants used in the EFI PE/COFF header which
can only be
On 30 July 2014 16:18, Matt Fleming m...@console-pimps.org wrote:
On Mon, 21 Jul, at 05:16:19PM, Ard Biesheuvel wrote:
Similar to how text offset and kernel size are mangled to produce little
endian constants for the Image header regardless of the endianness of the
kernel, this adds a number
On Wed, Jul 30, 2014 at 03:18:05PM +0100, Matt Fleming wrote:
On Mon, 21 Jul, at 05:16:19PM, Ard Biesheuvel wrote:
Similar to how text offset and kernel size are mangled to produce little
endian constants for the Image header regardless of the endianness of the
kernel, this adds a number of
On Wed, 30 Jul, at 12:29:32AM, Borislav Petkov wrote:
On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
The current debug print in EFI does
[0.00] efi: mem84: type=3, attr=0xf,
range=[0x645b5000-0x645fb000) (0MB)
and rounds off the size to 0MB
On 07/30/14 12:58, Borislav Petkov wrote:
On Wed, Jul 30, 2014 at 10:21:26AM -0700, H. Peter Anvin wrote:
Arguably the exactness is available in the range...
... and the size too. FWIW, other region dumps don't even print size:
[0.00] e820: BIOS-provided physical RAM map:
[
18 matches
Mail list logo
