|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH MM-PART3 v2 12/12] xen/arm: mm: Remove set_pte_flags_on_range()
On Tue, 14 May 2019, Julien Grall wrote:
> set_pte_flags_on_range() is yet another function that will open-code
> update to a specific range in the Xen page-tables. It can be completely
> dropped by using either modify_xen_mappings() or destroy_xen_mappings().
>
> Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
> Reviewed-by: Andrii Anisov <andrii_anisov@xxxxxxxx>
>
> ---
> Changes in v2:
> - Add missing newline in panic
> - Add Andrii's reviewed-by
> ---
> xen/arch/arm/mm.c | 58
> ++++++++++---------------------------------------------
> 1 file changed, 10 insertions(+), 48 deletions(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 23ca61e8f0..d74101bcd2 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1277,52 +1277,6 @@ int modify_xen_mappings(unsigned long s, unsigned long
> e, unsigned int flags)
> return xen_pt_update(s, INVALID_MFN, (e - s) >> PAGE_SHIFT, flags);
> }
>
> -enum mg { mg_clear, mg_ro, mg_rw, mg_rx };
> -static void set_pte_flags_on_range(const char *p, unsigned long l, enum mg
> mg)
> -{
> - lpae_t pte;
> - int i;
> -
> - ASSERT(is_kernel(p) && is_kernel(p + l));
> -
> - /* Can only guard in page granularity */
> - ASSERT(!((unsigned long) p & ~PAGE_MASK));
> - ASSERT(!(l & ~PAGE_MASK));
> -
> - for ( i = (p - _start) / PAGE_SIZE;
> - i < (p + l - _start) / PAGE_SIZE;
> - i++ )
> - {
> - pte = xen_xenmap[i];
> - switch ( mg )
> - {
> - case mg_clear:
> - pte.pt.valid = 0;
> - break;
> - case mg_ro:
> - pte.pt.valid = 1;
> - pte.pt.pxn = 1;
> - pte.pt.xn = 1;
> - pte.pt.ro = 1;
> - break;
> - case mg_rw:
> - pte.pt.valid = 1;
> - pte.pt.pxn = 1;
It shouldn't make any difference, but FYI we don't set pxn in
xen_pt_update.
> - pte.pt.xn = 1;
> - pte.pt.ro = 0;
> - break;
> - case mg_rx:
> - pte.pt.valid = 1;
> - pte.pt.pxn = 0;
> - pte.pt.xn = 0;
> - pte.pt.ro = 1;
> - break;
> - }
> - write_pte(xen_xenmap + i, pte);
> - }
> - flush_xen_tlb_local();
> -}
> -
> /* Release all __init and __initdata ranges to be reused */
> void free_init_memory(void)
> {
> @@ -1331,8 +1285,12 @@ void free_init_memory(void)
> uint32_t insn;
> unsigned int i, nr = len / sizeof(insn);
> uint32_t *p;
> + int rc;
>
> - set_pte_flags_on_range(__init_begin, len, mg_rw);
> + rc = modify_xen_mappings((unsigned long)__init_begin,
> + (unsigned long)__init_end, PAGE_HYPERVISOR_RW);
> + if ( rc )
> + panic("Unable to map RW the init section (rc = %d)\n", rc);
Like for the previous patch, I wonder if we should replace ASSERTs with
panics: ASSERTs don't cause issues in non-debug builds. We don't really
have an "official policy" about this, but I have been going by the rule
of thumb that ASSERTs are really good to have while we need to be
careful with BUG_ON/panic because they might introduce instability (see
Linux policy not to have any.)
>
> /*
> * From now on, init will not be used for execution anymore,
> @@ -1350,7 +1308,11 @@ void free_init_memory(void)
> for ( i = 0; i < nr; i++ )
> *(p + i) = insn;
>
> - set_pte_flags_on_range(__init_begin, len, mg_clear);
> + rc = destroy_xen_mappings((unsigned long)__init_begin,
> + (unsigned long)__init_end);
> + if ( rc )
> + panic("Unable to remove the init section (rc = %d)\n", rc);
> +
> init_domheap_pages(pa, pa + len);
> printk("Freed %ldkB init memory.\n",
> (long)(__init_end-__init_begin)>>10);
> }
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |