From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] arm64: align PHYS_OFFSET to block size
Date: Wed, 25 Mar 2015 14:59:49 +0000 [thread overview]
Message-ID: <20150325145949.GE26903@localhost> (raw)
In-Reply-To: <1427125016-3873-5-git-send-email-ard.biesheuvel@linaro.org>
On Mon, Mar 23, 2015 at 04:36:56PM +0100, Ard Biesheuvel wrote:
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 16134608eecf..fd8434753372 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -49,13 +49,15 @@
> #ifdef CONFIG_ARM64_64K_PAGES
> #define BLOCK_SHIFT PAGE_SHIFT
> #define BLOCK_SIZE PAGE_SIZE
> -#define TABLE_SHIFT PMD_SHIFT
> #else
> #define BLOCK_SHIFT SECTION_SHIFT
> #define BLOCK_SIZE SECTION_SIZE
> -#define TABLE_SHIFT PUD_SHIFT
> #endif
>
> +#define TABLE_SHIFT (BLOCK_SHIFT + PAGE_SHIFT - 3)
> +#define TABLE_SIZE (1 << TABLE_SHIFT)
> +#define TABLE_MASK (~(TABLE_SIZE - 1))
> +
> #define KERNEL_START _text
> #define KERNEL_END _end
>
> @@ -237,7 +239,10 @@ ENTRY(stext)
> bl el2_setup // Drop to EL1, w20=cpu_boot_mode
>
> adrp x24, __PHYS_OFFSET
> - mov x23, #KIMAGE_OFFSET
> + and x23, x24, #~TABLE_MASK // image offset
> + and x24, x24, #TABLE_MASK // PHYS_OFFSET
> + mov x0, #KIMAGE_OFFSET
> + add x23, x23, x0
I'm still trying to figure out how this works. Does the code imply that
the kernel image can only be loaded within a block size of the
PHYS_OFFSET? If that's the case, it's not too flexible.
My thoughts were to make PHYS_OFFSET permanently 0 (i.e. get rid of it
entirely) or at least compute it at DT parsing time. I'm more inclined
for making it 0 assuming that it doesn't break anything else (vmemmap
virtual range may get slightly bigger but still not significant,
basically max_phys_addr / sizeof(struct page)).
--
Catalin
next prev parent reply other threads:[~2015-03-25 14:59 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 15:23 [RFC PATCH 0/3] arm64: relocatable kernel proof of concept Ard Biesheuvel
2015-03-16 15:23 ` [RFC PATCH 1/3] arm64: head.S: replace early literals with constant immediates Ard Biesheuvel
2015-03-16 17:14 ` Mark Rutland
2015-03-17 7:01 ` Ard Biesheuvel
2015-03-16 15:23 ` [RFC PATCH 2/3] arm64: add support for relocatable kernel Ard Biesheuvel
2015-03-16 15:23 ` [RFC PATCH 3/3] arm64/efi: use relocated kernel Ard Biesheuvel
2015-03-16 16:09 ` [RFC PATCH 0/3] arm64: relocatable kernel proof of concept Mark Rutland
2015-03-16 16:45 ` Ard Biesheuvel
2015-03-16 17:33 ` Mark Rutland
2015-03-16 17:43 ` Ard Biesheuvel
2015-03-17 16:20 ` Mark Rutland
2015-03-16 23:19 ` Kees Cook
2015-03-17 7:38 ` Ard Biesheuvel
2015-03-17 16:35 ` Mark Rutland
2015-03-17 16:40 ` Ard Biesheuvel
2015-03-17 16:43 ` Mark Rutland
2015-03-23 15:36 ` [PATCH 0/4] RFC: split text and linear mappings using tagged pointers Ard Biesheuvel
2015-03-23 15:36 ` [PATCH 1/4] arm64: use tagged pointers to distinguish kernel text from the linear mapping Ard Biesheuvel
2015-03-25 14:04 ` Catalin Marinas
2015-03-26 1:27 ` Mark Rutland
2015-03-23 15:36 ` [PATCH 2/4] arm64: fixmap: move translation tables to dedicated region Ard Biesheuvel
2015-03-26 1:28 ` Mark Rutland
2015-03-26 6:20 ` Ard Biesheuvel
2015-03-30 14:34 ` Mark Rutland
2015-03-23 15:36 ` [PATCH 3/4] arm64: move kernel text below PAGE_OFFSET Ard Biesheuvel
2015-03-25 14:10 ` Catalin Marinas
2015-03-23 15:36 ` [PATCH 4/4] arm64: align PHYS_OFFSET to block size Ard Biesheuvel
2015-03-25 14:14 ` Catalin Marinas
2015-03-26 6:23 ` Ard Biesheuvel
2015-03-25 14:59 ` Catalin Marinas [this message]
2015-03-26 6:22 ` Ard Biesheuvel
2015-03-27 13:16 ` Ard Biesheuvel
2015-03-30 13:49 ` Catalin Marinas
2015-03-30 14:00 ` Ard Biesheuvel
2015-03-30 14:55 ` Mark Rutland
2015-03-30 15:00 ` Catalin Marinas
2015-03-30 18:08 ` Ard Biesheuvel
2015-03-31 14:49 ` Catalin Marinas
2015-03-31 16:19 ` Catalin Marinas
2015-03-31 16:46 ` Catalin Marinas
2015-03-26 1:26 ` [PATCH 0/4] RFC: split text and linear mappings using tagged pointers Mark Rutland
2015-03-26 6:09 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150325145949.GE26903@localhost \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).