All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Xia, Hongyan" <hongyax@amazon.com>
To: "julien.grall@arm.com" <julien.grall@arm.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Cc: "sstabellini@kernel.org" <sstabellini@kernel.org>,
	"Volodymyr_Babchuk@epam.com" <Volodymyr_Babchuk@epam.com>
Subject: Re: [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early
Date: Fri, 11 Oct 2019 09:53:35 +0000	[thread overview]
Message-ID: <0acfc39467986475acddea19da96b55f2468b8fe.camel@amazon.com> (raw)
In-Reply-To: <20190917160202.16770-1-julien.grall@arm.com>

Not commenting on the patch, but I had exactly the same problem when
removing the direct map in x86. map_domain_page has to be usable
without the direct map and even before alloc_boot_pages can be used (so
that I can map the bootmem_regions_list, although I have made it
statically allocated now).

The direct map teardown series in the end introduces a persistent
mapping infrastructure to map page tables which occupies a few fixmap
entries, and avoid set_fixmap but instead modify the entries directly
to avoid invocation loops. The result is that map_xen_pagetable and
map_domain_page is usable from the very beginning of start_xen.

Hongyan

On Tue, 2019-09-17 at 17:02 +0100, Julien Grall wrote:
> The current implementations of xen_{map, unmap}_table() expect
> {map, unmap}_domain_page() to be usable. Those helpers are used to
> map/unmap page tables while update Xen page-tables.
> 
> Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update
> in
> {set, clear}_fixmap()", setup_fixmap() will make use of the helpers
> mentioned above. When booting Xen using GRUB, setup_fixmap() may be
> used
> before map_domain_page() can be called. This will result to data
> abort:
> 
> (XEN) Data Abort Trap. Syndrome=0x5
> (XEN) CPU0: Unexpected Trap: Data Abort
> 
> [...]
> 
> (XEN) Xen call trace:
> (XEN)    [<000000000025ab6c>] mm.c#xen_pt_update+0x2b4/0x59c (PC)
> (XEN)    [<000000000025ab20>] mm.c#xen_pt_update+0x268/0x59c (LR)
> (XEN)    [<000000000025ae70>] set_fixmap+0x1c/0x2c
> (XEN)    [<00000000002a9c98>] copy_from_paddr+0x7c/0xdc
> (XEN)    [<00000000002a4ae0>] has_xsm_magic+0x18/0x34
> (XEN)    [<00000000002a5b5c>] bootfdt.c#early_scan_node+0x398/0x560
> (XEN)    [<00000000002a5de0>] device_tree_for_each_node+0xbc/0x144
> (XEN)    [<00000000002a5ed4>] boot_fdt_info+0x6c/0x260
> (XEN)    [<00000000002ac0d0>] start_xen+0x108/0xc74
> (XEN)    [<000000000020044c>] arm64/head.o#paging+0x60/0x88
> 
> During early boot, the page tables are either statically allocated in
> Xen binary or allocated via alloc_boot_pages().
> 
> For statically allocated page-tables, they will already be mapped as
> part of Xen binary. So we can easily find the virtual address.
> 
> For dynamically allocated page-tables, we need to rely
> map_domain_page() to be functionally working.
> 
> For arm32, the call will be usable much before page can be
> dynamically
> allocated (see setup_pagetables()). For arm64, the call will be
> usable
> after setup_xenheap_mappings().
> 
> In both cases, memory are given to the boot allocator afterwards. So
> we
> can rely on map_domain_page() for mapping page tables allocated
> dynamically.
> 
> The helpers xen_{map, unmap}_table() are now updated to take into
> account the case where page-tables are part of Xen binary.
> 
> Fixes: 022387ee1a ('xen/arm: mm: Don't open-code Xen PT update in
> {set, clear}_fixmap()')
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/arch/arm/mm.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index e1cdeaaf2f..da6303a8fd 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -950,11 +950,31 @@ static int create_xen_table(lpae_t *entry)
>  
>  static lpae_t *xen_map_table(mfn_t mfn)
>  {
> +    /*
> +     * We may require to map the page table before map_domain_page()
> is
> +     * useable. The requirements here is it must be useable as soon
> as
> +     * page-tables are allocated dynamically via alloc_boot_pages().
> +     */
> +    if ( system_state == SYS_STATE_early_boot )
> +    {
> +        vaddr_t va = mfn_to_maddr(mfn) - phys_offset;
> +
> +        if ( is_kernel(va) )
> +            return (lpae_t *)va;
> +    }
> +
>      return map_domain_page(mfn);
>  }
>  
>  static void xen_unmap_table(const lpae_t *table)
>  {
> +    /*
> +     * During early boot, xen_map_table() will not use
> map_domain_page()
> +     * for page-tables residing in Xen binary. So skip the unmap
> part.
> +     */
> +    if ( system_state == SYS_STATE_early_boot && is_kernel(table) )
> +        return;
> +
>      unmap_domain_page(table);
>  }
>  
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  parent reply	other threads:[~2019-10-11  9:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 16:02 [Xen-devel] [[PATCH for-4.13]] xen/arm: mm: Allow generic xen page-tables helpers to be called early Julien Grall
2019-09-19 23:37 ` Stefano Stabellini
2019-09-20  9:44   ` Julien Grall
2019-09-20 15:16     ` Stefano Stabellini
2019-09-20 15:26       ` Julien Grall
2019-10-02 17:49         ` Julien Grall
2019-10-03  1:02         ` Stefano Stabellini
2019-10-07 20:35           ` Julien Grall
2019-10-08  0:18             ` Stefano Stabellini
2019-10-08 14:02               ` Julien Grall
2019-10-08 22:24                 ` Stefano Stabellini
2019-10-10 16:56                   ` Julien Grall
2019-10-11  0:32                     ` Stefano Stabellini
2019-10-11 10:14                       ` Julien Grall
2019-10-11 17:11                         ` Stefano Stabellini
2019-10-11 17:51                           ` Julien Grall
2019-10-11 19:01                             ` Stefano Stabellini
2019-10-11 19:14                               ` Julien Grall
2019-09-25 15:23 ` Julien Grall
2019-09-25 15:27   ` Jürgen Groß
2019-10-11  9:53 ` Xia, Hongyan [this message]
2019-10-16 12:46   ` Julien Grall
2019-10-16 13:16     ` Xia, Hongyan
2019-10-10 17:52 [Xen-devel] [PATCH for-4.13] " Julien Grall
2019-10-11  0:27 ` Stefano Stabellini
2019-10-11 13:06   ` Julien Grall
2019-10-11 13:33   ` 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=0acfc39467986475acddea19da96b55f2468b8fe.camel@amazon.com \
    --to=hongyax@amazon.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=julien.grall@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.