From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien@xen.org>
Cc: xen-devel@lists.xenproject.org, Wei.Chen@arm.com,
Henry.Wang@arm.com, Penny.Zheng@arm.com,
Bertrand.Marquis@arm.com, Julien Grall <julien.grall@arm.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
Julien Grall <jgrall@amazon.com>
Subject: Re: [PATCH RFCv2 14/15] xen/arm: mm: Rework setup_xenheap_mappings()
Date: Fri, 14 May 2021 16:51:11 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.21.2105141646340.14426@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20210425201318.15447-15-julien@xen.org>
On Sun, 25 Apr 2021, Julien Grall wrote:
> From: Julien Grall <julien.grall@arm.com>
>
> A few issues have been reported with setup_xenheap_mappings() over the
> last couple of years. The main ones are:
> - It will break on platform supporting more than 512GB of RAM
> because the memory allocated by the boot allocator is not yet
> mapped.
> - Aligning all the regions to 1GB may lead to unexpected result
> because we may alias non-cacheable region (such as device or reserved
> regions).
>
> map_pages_to_xen() was recently reworked to allow superpage mappings and
> deal with the use of page-tables before they are mapped.
>
> Most of the code in setup_xenheap_mappings() is now replaced with a
> single call to map_pages_to_xen().
>
> This also require to re-order the steps setup_mm() so the regions are
> given to the boot allocator first and then we setup the xenheap
> mappings.
I know this is paranoia but doesn't this introduce a requirement on the
size of the first bank in bootinfo.mem.bank[] ?
It should be at least 8KB?
I know it is unlikely but it is theoretically possible to have a first
bank of just 1KB.
I think we should write the requirement down with an in-code comment?
Or better maybe we should write a message about it in the panic below?
> Note that the 1GB alignment is not yet removed.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> Signed-off-by: Julien Grall <jgrall@amazon.com>
>
> ---
> Changes in v2:
> - New patch
>
> TODO:
> - Remove the 1GB alignment
> - Add support for setting the contiguous bit
> ---
> xen/arch/arm/mm.c | 60 ++++----------------------------------------
> xen/arch/arm/setup.c | 10 ++++++--
I love it!
> 2 files changed, 13 insertions(+), 57 deletions(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index f5768f2d4a81..c49403b687f5 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -143,17 +143,6 @@ static DEFINE_PAGE_TABLE(cpu0_pgtable);
> static DEFINE_PAGE_TABLES(cpu0_dommap, DOMHEAP_SECOND_PAGES);
> #endif
>
> -#ifdef CONFIG_ARM_64
> -/* The first page of the first level mapping of the xenheap. The
> - * subsequent xenheap first level pages are dynamically allocated, but
> - * we need this one to bootstrap ourselves. */
> -static DEFINE_PAGE_TABLE(xenheap_first_first);
> -/* The zeroeth level slot which uses xenheap_first_first. Used because
> - * setup_xenheap_mappings otherwise relies on mfn_to_virt which isn't
> - * valid for a non-xenheap mapping. */
> -static __initdata int xenheap_first_first_slot = -1;
> -#endif
> -
> /* Common pagetable leaves */
> /* Second level page tables.
> *
> @@ -818,9 +807,9 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
> void __init setup_xenheap_mappings(unsigned long base_mfn,
> unsigned long nr_mfns)
> {
> - lpae_t *first, pte;
> unsigned long mfn, end_mfn;
> vaddr_t vaddr;
> + int rc;
>
> /* Align to previous 1GB boundary */
> mfn = base_mfn & ~((FIRST_SIZE>>PAGE_SHIFT)-1);
> @@ -846,49 +835,10 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
> */
> vaddr = (vaddr_t)__mfn_to_virt(base_mfn) & FIRST_MASK;
>
> - while ( mfn < end_mfn )
> - {
> - int slot = zeroeth_table_offset(vaddr);
> - lpae_t *p = &xen_pgtable[slot];
> -
> - if ( p->pt.valid )
> - {
> - /* mfn_to_virt is not valid on the 1st 1st mfn, since it
> - * is not within the xenheap. */
> - first = slot == xenheap_first_first_slot ?
> - xenheap_first_first : mfn_to_virt(lpae_get_mfn(*p));
> - }
> - else if ( xenheap_first_first_slot == -1)
> - {
> - /* Use xenheap_first_first to bootstrap the mappings */
> - first = xenheap_first_first;
> -
> - pte = pte_of_xenaddr((vaddr_t)xenheap_first_first);
> - pte.pt.table = 1;
> - write_pte(p, pte);
> -
> - xenheap_first_first_slot = slot;
> - }
> - else
> - {
> - mfn_t first_mfn = alloc_boot_pages(1, 1);
> -
> - clear_page(mfn_to_virt(first_mfn));
> - pte = mfn_to_xen_entry(first_mfn, MT_NORMAL);
> - pte.pt.table = 1;
> - write_pte(p, pte);
> - first = mfn_to_virt(first_mfn);
> - }
> -
> - pte = mfn_to_xen_entry(_mfn(mfn), MT_NORMAL);
> - /* TODO: Set pte.pt.contig when appropriate. */
> - write_pte(&first[first_table_offset(vaddr)], pte);
> -
> - mfn += FIRST_SIZE>>PAGE_SHIFT;
> - vaddr += FIRST_SIZE;
> - }
> -
> - flush_xen_tlb_local();
> + rc = map_pages_to_xen(vaddr, _mfn(mfn), end_mfn - mfn,
> + PAGE_HYPERVISOR_RW | _PAGE_BLOCK);
> + if ( rc )
> + panic("Unable to setup the xenheap mappings.\n");
This is the panic I was talking about
> }
> #endif
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 00aad1c194b9..0993a4bb52d4 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -761,8 +761,11 @@ static void __init setup_mm(void)
> ram_start = min(ram_start,bank_start);
> ram_end = max(ram_end,bank_end);
>
> - setup_xenheap_mappings(bank_start>>PAGE_SHIFT, bank_size>>PAGE_SHIFT);
> -
> + /*
> + * Add the region to the boot allocator first, so we can use
> + * some to allocate page-tables for setting up the xenheap
> + * mappings.
> + */
> s = bank_start;
> while ( s < bank_end )
> {
> @@ -781,6 +784,9 @@ static void __init setup_mm(void)
> fw_unreserved_regions(s, e, init_boot_pages, 0);
> s = n;
> }
> +
> + setup_xenheap_mappings(bank_start >> PAGE_SHIFT,
> + bank_size >> PAGE_SHIFT);
> }
>
> total_pages += ram_size >> PAGE_SHIFT;
> --
> 2.17.1
>
next prev parent reply other threads:[~2021-05-14 23:51 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-25 20:13 [PATCH RFCv2 00/15] xen/arm: mm: Remove open-coding mappings Julien Grall
2021-04-25 20:13 ` [PATCH RFCv2 01/15] xen/arm: lpae: Rename LPAE_ENTRIES_MASK_GS to LPAE_ENTRY_MASK_GS Julien Grall
2021-05-11 22:12 ` Stefano Stabellini
2021-04-25 20:13 ` [PATCH RFCv2 02/15] xen/arm: lpae: Use the generic helpers to defined the Xen PT helpers Julien Grall
2021-05-11 22:26 ` Stefano Stabellini
2021-05-12 14:26 ` Julien Grall
2021-05-12 21:30 ` Stefano Stabellini
2021-05-12 22:16 ` Julien Grall
2021-05-13 22:44 ` Stefano Stabellini
2021-07-03 17:32 ` Julien Grall
2021-07-13 20:53 ` Stefano Stabellini
2021-07-14 17:40 ` Julien Grall
2021-04-25 20:13 ` [PATCH RFCv2 03/15] xen/arm: p2m: Replace level_{orders, masks} arrays with LEVEL_{ORDER, MASK} Julien Grall
2021-05-11 22:33 ` Stefano Stabellini
2021-05-12 14:39 ` Julien Grall
2021-04-25 20:13 ` [PATCH RFCv2 04/15] xen/arm: mm: Allow other mapping size in xen_pt_update_entry() Julien Grall
2021-05-11 22:42 ` Stefano Stabellini
2021-04-25 20:13 ` [PATCH RFCv2 05/15] xen/arm: mm: Avoid flushing the TLBs when mapping are inserted Julien Grall
2021-05-11 22:51 ` Stefano Stabellini
2021-04-25 20:13 ` [PATCH RFCv2 06/15] xen/arm: mm: Don't open-code Xen PT update in remove_early_mappings() Julien Grall
2021-05-11 22:58 ` Stefano Stabellini
2021-04-25 20:13 ` [PATCH RFCv2 07/15] xen/arm: mm: Re-implement early_fdt_map() using map_pages_to_xen() Julien Grall
2021-05-12 21:41 ` Stefano Stabellini
2021-05-12 22:18 ` Julien Grall
2021-04-25 20:13 ` [PATCH RFCv2 08/15] xen/arm32: mm: Check if the virtual address is shared before updating it Julien Grall
2021-05-12 22:00 ` Stefano Stabellini
2021-05-12 22:23 ` Julien Grall
2021-05-13 22:32 ` Stefano Stabellini
2021-05-13 22:59 ` Julien Grall
2021-05-14 1:04 ` Stefano Stabellini
2021-04-25 20:13 ` [PATCH RFCv2 09/15] xen/arm32: mm: Re-implement setup_xenheap_mappings() using map_pages_to_xen() Julien Grall
2021-05-12 22:07 ` Stefano Stabellini
2021-05-13 17:55 ` Julien Grall
2021-04-25 20:13 ` [PATCH RFCv2 10/15] xen/arm: mm: Allocate xen page tables in domheap rather than xenheap Julien Grall
2021-05-12 22:44 ` Stefano Stabellini
2021-05-13 18:09 ` Julien Grall
2021-05-13 22:27 ` Stefano Stabellini
2021-05-15 8:48 ` Julien Grall
2021-05-18 0:37 ` Stefano Stabellini
2021-04-25 20:13 ` [PATCH RFCv2 11/15] xen/arm: mm: Allow page-table allocation from the boot allocator Julien Grall
2021-05-13 22:58 ` Stefano Stabellini
2021-04-25 20:13 ` [PATCH RFCv2 12/15] xen/arm: add Persistent Map (PMAP) infrastructure Julien Grall
2021-04-26 9:41 ` Xia, Hongyan
2021-07-03 17:57 ` Julien Grall
2021-04-28 21:47 ` Wei Liu
2021-05-14 23:25 ` Stefano Stabellini
2021-05-15 8:54 ` Julien Grall
2021-04-25 20:13 ` [PATCH RFCv2 13/15] xen/arm: mm: Use the PMAP helpers in xen_{,un}map_table() Julien Grall
2021-05-14 23:35 ` Stefano Stabellini
2021-05-15 9:03 ` Julien Grall
2021-04-25 20:13 ` [PATCH RFCv2 14/15] xen/arm: mm: Rework setup_xenheap_mappings() Julien Grall
2021-05-14 23:51 ` Stefano Stabellini [this message]
2021-05-15 9:21 ` Julien Grall
2021-05-18 0:50 ` Stefano Stabellini
2022-02-12 19:16 ` Julien Grall
2021-04-25 20:13 ` [PATCH RFCv2 15/15] xen/arm: mm: Re-implement setup_frame_table_mappings() with map_pages_to_xen() Julien Grall
2021-05-15 0:02 ` Stefano Stabellini
2021-05-15 9:25 ` Julien Grall
2021-05-18 0:51 ` Stefano Stabellini
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=alpine.DEB.2.21.2105141646340.14426@sstabellini-ThinkPad-T480s \
--to=sstabellini@kernel.org \
--cc=Bertrand.Marquis@arm.com \
--cc=Henry.Wang@arm.com \
--cc=Penny.Zheng@arm.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=Wei.Chen@arm.com \
--cc=jgrall@amazon.com \
--cc=julien.grall@arm.com \
--cc=julien@xen.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).