From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [Xen-devel] [PATCH v3 27/28] xen/arm32: head: Introduce macros to create table and mapping entry
Date: Fri, 23 Aug 2019 10:40:51 +0100 [thread overview]
Message-ID: <ad9abfec-f947-8147-39e3-62f0b3a38fdb@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1908221645070.25445@sstabellini-ThinkPad-T480s>
Hi Stefano,
On 23/08/2019 02:10, Stefano Stabellini wrote:
> On Mon, 12 Aug 2019, Julien Grall wrote:
>> At the moment, any update to the boot-pages are open-coded. This is
>> making more difficult to understand the logic of a function as each
>> update roughly requires 6 instructions.
>>
>> To ease the readability, two new macros are introduced:
>> - create_table_entry: Create a page-table entry in a given table.
>> This can work at any level.
>> - create_mapping_entry: Create a mapping entry in a given table.
>> None of the users will require to map at any other level than 3rd
>> (i.e page granularity). So the macro is supporting support 3rd level
>> mapping.
>>
>> Unlike arm64, there are no easy way to have a PC relative address within
>> the range -/+4GB. In order to have the possibility to use the macro in
>> context with MMU on/off, the user needs to tell the state of the MMU.
>>
>> Lastly, take the opportunity to replace open-coded version in
>> setup_fixmap() by the two new macros. The ones in create_page_tables()
>> will be replaced in a follow-up patch.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>
>> ---
>> The adr_l hack is a bit ugly, but I can't find nicer way to avoid
>> code duplication and improve readability.
>>
>> Changes in v3:
>> - Patch added
>> ---
>> xen/arch/arm/arm32/head.S | 108 ++++++++++++++++++++++++++++++++++++++--------
>> 1 file changed, 89 insertions(+), 19 deletions(-)
>>
>> diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
>> index e86a9f95e7..6d03fecaf2 100644
>> --- a/xen/arch/arm/arm32/head.S
>> +++ b/xen/arch/arm/arm32/head.S
>> @@ -50,6 +50,20 @@
>> .endm
>>
>> /*
>> + * There are no easy way to have a PC relative address within the range
>> + * +/- 4GB of the PC.
>> + *
>> + * This macro workaround it by asking the user to tell whether the MMU
>> + * has been turned on or not.
>
> I would add one statement saying why we are using r10 below in the
> implementation. Just a suggestion to make things clearer.
Sure.
>
>
>> + */
>> +.macro adr_l, dst, sym, mmu
>> + ldr \dst, =\sym
>> + .if \mmu == 0
>> + add \dst, \dst, r10
>> + .endif
>> +.endm
>> +
>> +/*
>> * Common register usage in this file:
>> * r0 -
>> * r1 -
>> @@ -342,6 +356,76 @@ cpu_init_done:
>> ENDPROC(cpu_init)
>>
>> /*
>> + * Macro to create a page table entry in \ptbl to \tbl
>> + *
>> + * ptbl: table symbol where the entry will be created
>> + * tbl: table symbol to point to
>> + * virt: virtual address
>> + * shift: #imm page table shift
>> + * mmu: Is the MMU turned on/off. If not specified it will be off
>> + *
>> + * Preserves \virt
>> + * Clobbers r1 - r4
>
> In the 64bit version you added the temp registers to the parameter list.
> Why do things differently here, hard-coding the usage of r1-r4?
A few reasons:
1) There are 2 more parameters for the arm32 version (one more tmp register
+ mmu). So the line will be far over 80 characters. A split of the line will not
be inline with the idea of one line per "instruction" within the file.
2) strd impose the two registers that will be stored to be contiguous (the
start register should be an even number). So we would have to convey it to the user.
arm64 version is using the parameter list because I feel macro is not meant to
modify pre-defined registers. I am aware this is what we do on arm32 but we also
have symbols in parameters and a function would not have made things much better
in the callers (you would have to load all symbols in registers before hand).
So this is the best compromised I have found.
>
>
>> + * Also use r10 for the phys offset.
>> + *
>> + * Note that \virt should be in a register other than r1 - r4
>> + */
>> +.macro create_table_entry, ptbl, tbl, virt, shift, mmu=0
>> + lsr r1, \virt, #\shift
>> + mov_w r2, LPAE_ENTRY_MASK
>> + and r1, r1, r2 /* r1 := slot in \tlb */
>> + lsl r1, r1, #3 /* r1 := slot offset in \tlb */
>> +
>> + ldr r4, =\tbl
>> + add r4, r4, r10 /* r4 := paddr(\tlb) */
>
> you could use adr_l?
adr_l is for loading relative address. Here we want the physical address
regarding the state of the MMU.
>> + mov r2, #PT_PT /* r2:r3 := right for linear PT */
>> + orr r2, r2, r4 /* + \tlb paddr */
>> + mov r3, #0
>> +
>> + adr_l r4, \ptbl, \mmu
>> +
>> + strd r2, r3, [r4, r1]
>> +.endm
>> +
>> +/*
>> + * Macro to create a mapping entry in \tbl to \paddr. Only mapping in 3rd
>> + * level table (i.e page granularity) is supported.
>> + *
>> + * tbl: table symbol where the entry will be created
>> + * virt: virtual address
>> + * phys: physical address
>> + * type: mapping type. If not specified it will be normal memory (PT_MEM_L3)
>> + * mmu: Is the MMU turned on/off. If not specified it will be off
>> + *
>> + * Preserves \virt, \phys
>> + * Clobbers r1 - r4
>
> Same here
>
>
>> + * * Also use r10 for the phys offset.
>> + *
>> + * Note that \virt and \paddr should be in other registers than r1 - r4
>> + * and be distinct.
>> + */
>> +.macro create_mapping_entry, tbl, virt, phys, type=PT_MEM_L3, mmu=0
>> + lsr r4, \phys, #THIRD_SHIFT
>> + lsl r4, r4, #THIRD_SHIFT /* r4 := PAGE_ALIGNED(phys) */
>
> and THIRD_MASK like for arm64? Doesn't really matter but it would be
> nicer if we could keep them similar.
I am with you on this point. But sometimes it is not possible (they are two
distinct instructions set with similarities) or make the code less obvious for
the arch.
In this case, the instruction 'and' is taking a "modified immediate constant".
The immediate will be encoded as an 8-bit number than can be rotate.
The value of THIRD_MASK is 0xfffffffffffff000. Therefore it can't be encoded as
an immediate for the instruction 'and'.
One solution would be to load the immediate in a register, and then using the
instruction 'and'. But I felt, the lsr/lsl solution was nicer.
>
>
>> + mov_w r2, LPAE_ENTRY_MASK
>> + lsr r1, \virt, #THIRD_SHIFT
>> + and r1, r1, r2 /* r1 := slot in \tlb */
>> + lsl r1, r1, #3 /* r1 := slot offset in \tlb */
>
> I would prefer if you moved these for lines up, like you have down in
> create_table_entry, it is clearer to read for me. Just an optional
> suggestion.
Sure.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-08-23 9:41 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-12 17:29 [Xen-devel] [PATCH v3 00/28] xen/arm: Rework head.S to make it more compliant with the Arm Arm Julien Grall
2019-08-12 17:29 ` [Xen-devel] [PATCH v3 01/28] xen/arm: lpae: Allow more LPAE helpers to be used in assembly Julien Grall
2019-08-22 17:07 ` Stefano Stabellini
2019-08-12 17:29 ` [Xen-devel] [PATCH v3 02/28] xen/arm64: head: Remove 1:1 mapping as soon as it is not used Julien Grall
2019-08-22 17:58 ` Stefano Stabellini
2019-08-22 18:25 ` Julien Grall
2019-08-22 18:29 ` Stefano Stabellini
2019-08-12 17:29 ` [Xen-devel] [PATCH v3 03/28] xen/arm64: head: Rework and document setup_fixmap() Julien Grall
2019-08-12 17:29 ` [Xen-devel] [PATCH v3 04/28] xen/arm64: head: Rework and document launch() Julien Grall
2019-08-12 17:29 ` [Xen-devel] [PATCH v3 05/28] xen/arm64: head: Setup TTBR_EL2 in enable_mmu() and add missing isb Julien Grall
2019-08-12 17:29 ` [Xen-devel] [PATCH v3 06/28] xen/arm64: head: Introduce a macro to get a PC-relative address of a symbol Julien Grall
2019-08-12 17:29 ` [Xen-devel] [PATCH v3 07/28] xen/arm64: head: Fix typo in the documentation on top of init_uart() Julien Grall
2019-08-22 17:08 ` Stefano Stabellini
2019-08-12 17:29 ` [Xen-devel] [PATCH v3 08/28] xen/arm32: head: Add a macro to move an immediate constant into a 32-bit register Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 09/28] xen/arm32: head: Mark the end of subroutines with ENDPROC Julien Grall
2019-08-12 17:33 ` Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 10/28] xen/arm32: head: Don't clobber r14/lr in the macro PRINT Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 11/28] xen/arm32: head: Rework UART initialization on boot CPU Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 12/28] xen/arm32: head: Introduce print_reg Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 13/28] xen/arm32: head: Introduce distinct paths for the boot CPU and secondary CPUs Julien Grall
2019-08-22 17:11 ` Stefano Stabellini
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 14/28] xen/arm32: head: Rework and document check_cpu_mode() Julien Grall
2019-08-22 17:14 ` Stefano Stabellini
2019-09-07 10:35 ` Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 15/28] xen/arm32: head: Rework and document zero_bss() Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 16/28] xen/arm32: head: Document create_pages_tables() Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 17/28] xen/arm32: head: Document enable_mmu() Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 18/28] xen/arm32: head: Move assembly switch to the runtime PT in secondary CPUs path Julien Grall
2019-08-22 17:17 ` Stefano Stabellini
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 19/28] xen/arm32: head: Don't setup the fixmap on secondary CPUs Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 20/28] xen/arm32: head: Remove 1:1 mapping as soon as it is not used Julien Grall
2019-08-22 18:17 ` Stefano Stabellini
2019-08-22 18:31 ` Julien Grall
2019-08-22 22:53 ` Stefano Stabellini
2019-08-22 23:39 ` Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 21/28] xen/arm32: head: Rework and document setup_fixmap() Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 22/28] xen/arm32: head: Rework and document launch() Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 23/28] xen/arm32: head: Setup HTTBR in enable_mmu() and add missing isb Julien Grall
2019-08-22 17:15 ` Stefano Stabellini
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 24/28] xen/arm: Zero BSS after the MMU and D-cache is turned on Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 25/28] xen/arm64: head: Introduce macros to create table and mapping entry Julien Grall
2019-08-22 23:31 ` Stefano Stabellini
2019-08-22 23:44 ` Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 26/28] xen/arm64: head: Use a page mapping for the 1:1 mapping in create_page_tables() Julien Grall
2019-08-24 1:16 ` Stefano Stabellini
2019-09-17 17:53 ` Julien Grall
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 27/28] xen/arm32: head: Introduce macros to create table and mapping entry Julien Grall
2019-08-23 1:10 ` Stefano Stabellini
2019-08-23 9:40 ` Julien Grall [this message]
2019-08-12 17:30 ` [Xen-devel] [PATCH v3 28/28] xen/arm32: head: Use a page mapping for the 1:1 mapping in create_page_tables() Julien Grall
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=ad9abfec-f947-8147-39e3-62f0b3a38fdb@arm.com \
--to=julien.grall@arm.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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).