All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Elias El Yandouzi <eliasely@amazon.com>
Cc: xen-devel@lists.xenproject.org, julien@xen.org,
	pdurrant@amazon.com, dwmw@amazon.com,
	Hongyan Xia <hongyxia@amazon.com>,
	Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <jgrall@amazon.com>
Subject: Re: [PATCH V3 (resend) 13/19] x86/setup: Do not create valid mappings when directmap=no
Date: Tue, 14 May 2024 17:39:20 +0200	[thread overview]
Message-ID: <ZkOFqFrSs41UtjIU@macbook> (raw)
In-Reply-To: <20240513134046.82605-14-eliasely@amazon.com>

On Mon, May 13, 2024 at 01:40:40PM +0000, Elias El Yandouzi wrote:
> From: Hongyan Xia <hongyxia@amazon.com>
> 
> Create empty mappings in the second e820 pass. Also, destroy existing
> direct map mappings created in the first pass.
> 
> To make xenheap pages visible in guests, it is necessary to create empty
> L3 tables in the direct map even when directmap=no, since guest cr3s
> copy idle domain's L4 entries, which means they will share mappings in
> the direct map if we pre-populate idle domain's L4 entries and L3
> tables. A helper is introduced for this.
> 
> Also, after the direct map is actually gone, we need to stop updating
> the direct map in update_xen_mappings().
> 
> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
> Signed-off-by: Julien Grall <jgrall@amazon.com>
> Signed-off-by: Elias El Yandouzi <eliasely@amazon.com>
> 
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index f26c9799e4..919347d8c2 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -978,6 +978,57 @@ static struct domain *__init create_dom0(const module_t *image,
>  /* How much of the directmap is prebuilt at compile time. */
>  #define PREBUILT_MAP_LIMIT (1 << L2_PAGETABLE_SHIFT)
>  
> +/*
> + * This either populates a valid direct map, or allocates empty L3 tables and
> + * creates the L4 entries for virtual address between [start, end) in the
> + * direct map depending on has_directmap();
> + *
> + * When directmap=no, we still need to populate empty L3 tables in the
> + * direct map region. The reason is that on-demand xenheap mappings are
> + * created in the idle domain's page table but must be seen by
> + * everyone. Since all domains share the direct map L4 entries, they
> + * will share xenheap mappings if we pre-populate the L4 entries and L3
> + * tables in the direct map region for all RAM. We also rely on the fact
> + * that L3 tables are never freed.
> + */
> +static void __init populate_directmap(uint64_t pstart, uint64_t pend,

paddr_t for both.

> +                                      unsigned int flags)
> +{
> +    unsigned long vstart = (unsigned long)__va(pstart);
> +    unsigned long vend = (unsigned long)__va(pend);
> +
> +    if ( pstart >= pend )
> +        return;
> +
> +    BUG_ON(vstart < DIRECTMAP_VIRT_START);
> +    BUG_ON(vend > DIRECTMAP_VIRT_END);
> +
> +    if ( has_directmap() )
> +        /* Populate valid direct map. */
> +        BUG_ON(map_pages_to_xen(vstart, maddr_to_mfn(pstart),
> +                                PFN_DOWN(pend - pstart), flags));
> +    else
> +    {
> +        /* Create empty L3 tables. */
> +        unsigned long vaddr = vstart & ~((1UL << L4_PAGETABLE_SHIFT) - 1);
> +
> +        for ( ; vaddr < vend; vaddr += (1UL << L4_PAGETABLE_SHIFT) )

It might be clearer (by avoiding some of the bitops and masks to simply
do:

for ( unsigned int idx = l4_table_offset(vstart);
      idx <= l4_table_offset(vend);
      idx++ )
{
...

> +        {
> +            l4_pgentry_t *pl4e = &idle_pg_table[l4_table_offset(vaddr)];
> +
> +            if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) )
> +            {
> +                mfn_t mfn = alloc_boot_pages(1, 1);

Hm, why not use alloc_xen_pagetable()?

> +                void *v = map_domain_page(mfn);
> +
> +                clear_page(v);
> +                UNMAP_DOMAIN_PAGE(v);

Maybe use clear_domain_page()?

> +                l4e_write(pl4e, l4e_from_mfn(mfn, __PAGE_HYPERVISOR));
> +            }
> +        }
> +    }
> +}
> +
>  void asmlinkage __init noreturn __start_xen(unsigned long mbi_p)
>  {
>      const char *memmap_type = NULL, *loader, *cmdline = "";
> @@ -1601,8 +1652,17 @@ void asmlinkage __init noreturn __start_xen(unsigned long mbi_p)
>          map_e = min_t(uint64_t, e,
>                        ARRAY_SIZE(l2_directmap) << L2_PAGETABLE_SHIFT);
>  
> -        /* Pass mapped memory to allocator /before/ creating new mappings. */
> +        /*
> +         * Pass mapped memory to allocator /before/ creating new mappings.
> +         * The direct map for the bottom 4GiB has been populated in the first
> +         * e820 pass. In the second pass, we make sure those existing mappings
> +         * are destroyed when directmap=no.

Quite likely a stupid question, but why has the directmap been
populated for memory below 4GB?  IOW: why do we need to create those
mappings just to have them destroyed here.

Thanks, Roger.


  reply	other threads:[~2024-05-14 15:39 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-13 13:40 [PATCH V3 (resend) 00/19] Remove the directmap Elias El Yandouzi
2024-05-13 13:40 ` [PATCH V3 (resend) 01/19] x86: Create per-domain mapping of guest_root_pt Elias El Yandouzi
2024-05-14 14:51   ` Jan Beulich
2024-05-15 18:25     ` Elias El Yandouzi
2024-05-16  7:17       ` Jan Beulich
2024-06-13 16:31         ` Elias El Yandouzi
2024-06-14  6:23           ` Jan Beulich
2024-06-17  7:33             ` Roger Pau Monné
2024-05-13 13:40 ` [PATCH V3 (resend) 02/19] x86/pv: Domheap pages should be mapped while relocating initrd Elias El Yandouzi
2024-05-13 15:40   ` Roger Pau Monné
2024-05-13 13:40 ` [PATCH V3 (resend) 03/19] x86/pv: Rewrite how building PV dom0 handles domheap mappings Elias El Yandouzi
2024-05-13 16:49   ` Roger Pau Monné
2024-05-14 14:58     ` Jan Beulich
2024-05-14 15:03   ` Jan Beulich
2024-07-16 16:12     ` Elias El Yandouzi
2024-07-17 10:45       ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 04/19] x86: Lift mapcache variable to the arch level Elias El Yandouzi
2024-05-14  8:21   ` Roger Pau Monné
2024-05-15 13:11   ` Jan Beulich
2024-07-16 17:06   ` Alejandro Vallejo
2024-07-17 12:41     ` Alejandro Vallejo
2024-05-13 13:40 ` [PATCH V3 (resend) 05/19] x86/mapcache: Initialise the mapcache for the idle domain Elias El Yandouzi
2024-05-14  8:42   ` Roger Pau Monné
2024-05-15 13:44     ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 06/19] x86: Add a boot option to enable and disable the direct map Elias El Yandouzi
2024-05-14  9:20   ` Roger Pau Monné
2024-05-14 10:20     ` Roger Pau Monné
2024-05-15 13:54     ` Jan Beulich
2024-05-16  9:19       ` Roger Pau Monné
2024-05-16  9:24         ` Jan Beulich
2024-05-15 13:59   ` Jan Beulich
2024-05-15 16:02   ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 07/19] xen/x86: Add support for the PMAP Elias El Yandouzi
2024-05-14  9:40   ` Roger Pau Monné
2024-05-14  9:43     ` Jan Beulich
2024-05-14 10:22       ` Roger Pau Monné
2024-05-14 10:26         ` Jan Beulich
2024-05-14 11:51           ` Roger Pau Monné
2024-05-14 12:33             ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 08/19] xen/x86: Add build assertion for fixmap entries Elias El Yandouzi
2024-05-14  9:42   ` Roger Pau Monné
2024-05-14  9:45     ` Jan Beulich
2024-05-15 14:03   ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 09/19] x86/domain_page: Remove the fast paths when mfn is not in the directmap Elias El Yandouzi
2024-05-14 11:48   ` Roger Pau Monné
2024-05-15 14:21   ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 10/19] xen/page_alloc: Add a path for xenheap when there is no direct map Elias El Yandouzi
2024-05-14 13:07   ` Roger Pau Monné
2024-05-15 15:13   ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 11/19] x86/setup: Leave early boot slightly earlier Elias El Yandouzi
2024-05-14 14:11   ` Roger Pau Monné
2024-05-15 15:22   ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 12/19] x86/setup: vmap heap nodes when they are outside the direct map Elias El Yandouzi
2024-05-14 15:02   ` Roger Pau Monné
2024-05-15 15:28   ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 13/19] x86/setup: Do not create valid mappings when directmap=no Elias El Yandouzi
2024-05-14 15:39   ` Roger Pau Monné [this message]
2024-05-15 15:50     ` Jan Beulich
2024-05-15 15:59   ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 14/19] Rename mfn_to_virt() calls Elias El Yandouzi
2024-05-14 15:45   ` Roger Pau Monné
2024-05-14 16:22     ` Jan Beulich
2024-05-15  9:38       ` Roger Pau Monné
2024-05-15  9:42         ` Jan Beulich
2024-05-16  8:57   ` Jan Beulich
2024-05-13 13:40 ` [PATCH V3 (resend) 15/19] Rename maddr_to_virt() calls Elias El Yandouzi
2024-05-13 13:40 ` [PATCH V3 (resend) 16/19] xen/arm32: mm: Rename 'first' to 'root' in init_secondary_pagetables() Elias El Yandouzi
2024-05-13 13:40 ` [PATCH V3 (resend) 17/19] xen/arm64: mm: Use per-pCPU page-tables Elias El Yandouzi
2024-05-13 13:40 ` [PATCH V3 (resend) 18/19] xen/arm64: Implement a mapcache for arm64 Elias El Yandouzi
2024-05-13 13:40 ` [PATCH V3 (resend) 19/19] xen/arm64: Allow the admin to enable/disable the directmap Elias El Yandouzi

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=ZkOFqFrSs41UtjIU@macbook \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dwmw@amazon.com \
    --cc=eliasely@amazon.com \
    --cc=hongyxia@amazon.com \
    --cc=jbeulich@suse.com \
    --cc=jgrall@amazon.com \
    --cc=julien@xen.org \
    --cc=pdurrant@amazon.com \
    --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.