[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/arm: Remove most of the *_VIRT_END defines


  • To: Julien Grall <julien@xxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Tue, 24 May 2022 08:05:34 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p0V/0EKDU4QbvIsakOyVn8J9zQAXeEYdpiceoXmiTHA=; b=nf/pJ8jeQgQv1uD7HP/eGqfIlWa6QkeCCV60NGBftJRL8GOx9m0WMnKiJu9CCcmqnxF6fjcAKcaOViB3ACL7sVlK80vPmQDyM91nol9e0PRR9x+D4cxwLRuG5znmnFWE49sbNGkCwQrnvq2WM0Ukx5+XAPdlr9LGUC+muos5ZfIZvV0PinIaRuW1YH3Oz9k9FJ7dOZI2GHh5S8dFCLcoSPnCMdhYR/ejzrL+Dyq25vEVf78Kv1z7XHBiXb+HDRJJ3pU6FmBKGnhhbbJ+iaRWeBzURsyQ4pSvNhem0IJOmT4JJWwuLsQdMrNR039+7vJCZJe/KsxKKEzL1s28wt9VXA==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=p0V/0EKDU4QbvIsakOyVn8J9zQAXeEYdpiceoXmiTHA=; b=U0B+mw/84B61kkx+PSb2LzYtEMo2UsDHELGUN7irUj5VxFrgF2mitJFU7VWSEr9r00azfE08v8C8Fyx1YPF+OAS8fo2/l+YitlxIKMZemwqo9syOj5lALhCYz2TjCEgeKUleQVbR/gqelMETnutuR0n+IJHvAEYQ2u9ZlolpCs3yZTOhyY1gsPI2FbvNkk0azYAkkarn7HWcNMkESMuCqSikufNCVDFie3OA3ZJW1FAXKq7DagV8m3kgreDE+I/lzNTbLCjB2JmAWo3Ny5ikrEDKmzuzjahOmSNP2Z9irGVPUcx/5Hzywia8JBKeo9w7ZSWbAP5xGXXb7FcSUOPKQQ==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=VJD5RoN2m1Pkvm/9pS03WbM+PHY7H8gbxfWmUgLzBJLJSG3JzGgqmlPu/bP48VEBEPyLH/x3Je09vqOHX3TTt6NELlKd2fTwG+KQ6QHb/3oNPWaFLY4s380rPY0ZbrzM+3YBmFew3IOj+VF3K4gJn3keS1/9JnweDfVwIUGN3SBRx16mJSJk8VzLgYxknPkcFUMv1ieFDFG3EULhAM1vrJZwCseDTyLuFhqol7+5jw9vCWEOplHUQIqsPyr1SxpyxR2Fp6esMHcQeFE2Yl+1F66tZ035jlOxQX9jPXhmzLZIJXrTZIkl81FprWuBe64ytO8002gtzeZffqUta4PAwA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c+54EepMqXWJ0I90wBcuEXj7cMsStKMaWQxVukDO05FRxhLJKKyJ7GUD0i89MMSVhIFdIDscA70QPys9QrgLR9EBYY02zJBtghR4WA0hTvuaViOo/47JjeMpm/qH8AvUY0VMPQqfhnvUAwScDtsrG30IkEf3GMnSdDYeLJVwse7MeS9rMeasMiPnXzy58/515+ERCj+MNmoxNAUO15qAPKPCOwiyKKKDelHWOWwzru3qWKDXxphCayL0YPhwhQDxtuOoOT5tho6JmgY9gniXL/kCli8cnfYomOlSHd3wnsdxdshHnFCKWA4qWXOV34QgLq6y1xNFlCvPeFCfrTzENg==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
  • Delivery-date: Tue, 24 May 2022 08:05:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYbt5OQ+9i9MqGEE+kzOfwd/8WE60trFiA
  • Thread-topic: [PATCH] xen/arm: Remove most of the *_VIRT_END defines

Hi Julien,

> On 23 May 2022, at 20:49, Julien Grall <julien@xxxxxxx> wrote:
> 
> From: Julien Grall <jgrall@xxxxxxxxxx>
> 
> At the moment, *_VIRT_END may either point to the address after the end
> or the last address of the region.
> 
> The lack of consistency make quite difficult to reason with them.
> 
> Furthermore, there is a risk of overflow in the case where the address
> points past to the end. I am not aware of any cases, so this is only a
> latent bug.
> 
> Start to solve the problem by removing all the *_VIRT_END exclusively used
> by the Arm code and add *_VIRT_SIZE when it is not present.
> 
> Take the opportunity to rename BOOT_FDT_SLOT_SIZE to BOOT_FDT_VIRT_SIZE
> for better consistency and use _AT(vaddr_t, ).

Thanks to have remembered this one :-)

> 
> Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx>
> 
> ----
> 
> I noticed that a few functions in Xen expect [start, end[. This is risky
> as we may end up with end < start if the region is defined right at the
> top of the address space.
> 
> I haven't yet tackle this issue. But I would at least like to get rid
> of *_VIRT_END.
> ---
> xen/arch/arm/include/asm/config.h | 18 ++++++++----------
> xen/arch/arm/livepatch.c          |  2 +-
> xen/arch/arm/mm.c                 | 13 ++++++++-----
> 3 files changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/arm/include/asm/config.h 
> b/xen/arch/arm/include/asm/config.h
> index 3e2a55a91058..66db618b34e7 100644
> --- a/xen/arch/arm/include/asm/config.h
> +++ b/xen/arch/arm/include/asm/config.h
> @@ -111,12 +111,11 @@
> #define FIXMAP_ADDR(n)        (_AT(vaddr_t,0x00400000) + (n) * PAGE_SIZE)
> 
> #define BOOT_FDT_VIRT_START    _AT(vaddr_t,0x00600000)
> -#define BOOT_FDT_SLOT_SIZE     MB(4)
> -#define BOOT_FDT_VIRT_END      (BOOT_FDT_VIRT_START + BOOT_FDT_SLOT_SIZE)
> +#define BOOT_FDT_VIRT_SIZE     _AT(vaddr_t, MB(4))
> 
> #ifdef CONFIG_LIVEPATCH
> #define LIVEPATCH_VMAP_START   _AT(vaddr_t,0x00a00000)
> -#define LIVEPATCH_VMAP_END     (LIVEPATCH_VMAP_START + MB(2))
> +#define LIVEPATCH_VMAP_SIZE    _AT(vaddr_t, MB(2))
> #endif
> 
> #define HYPERVISOR_VIRT_START  XEN_VIRT_START
> @@ -132,18 +131,18 @@
> #define FRAMETABLE_VIRT_END    (FRAMETABLE_VIRT_START + FRAMETABLE_SIZE - 1)
> 
> #define VMAP_VIRT_START        _AT(vaddr_t,0x10000000)
> +#define VMAP_VIRT_SIZE         _AT(vaddr_t, GB(1) - MB(256))

This looks a bit odd, any reason not to use MB(768) ?
If not then there might be something worse explaining with a comment here.

> 
> #define XENHEAP_VIRT_START     _AT(vaddr_t,0x40000000)
> -#define XENHEAP_VIRT_END       _AT(vaddr_t,0x7fffffff)
> -#define DOMHEAP_VIRT_START     _AT(vaddr_t,0x80000000)
> -#define DOMHEAP_VIRT_END       _AT(vaddr_t,0xffffffff)
> +#define XENHEAP_VIRT_SIZE      _AT(vaddr_t, GB(1))
> 
> -#define VMAP_VIRT_END    XENHEAP_VIRT_START
> +#define DOMHEAP_VIRT_START     _AT(vaddr_t,0x80000000)
> +#define DOMHEAP_VIRT_SIZE      _AT(vaddr_t, GB(2))
> 
> #define DOMHEAP_ENTRIES        1024  /* 1024 2MB mapping slots */
> 
> /* Number of domheap pagetable pages required at the second level (2MB 
> mappings) */
> -#define DOMHEAP_SECOND_PAGES ((DOMHEAP_VIRT_END - DOMHEAP_VIRT_START + 1) >> 
> FIRST_SHIFT)
> +#define DOMHEAP_SECOND_PAGES (DOMHEAP_VIRT_SIZE >> FIRST_SHIFT)
> 
> #else /* ARM_64 */
> 
> @@ -152,12 +151,11 @@
> #define SLOT0_ENTRY_SIZE  SLOT0(1)
> 
> #define VMAP_VIRT_START  GB(1)
> -#define VMAP_VIRT_END    (VMAP_VIRT_START + GB(1))
> +#define VMAP_VIRT_SIZE   GB(1)
> 
> #define FRAMETABLE_VIRT_START  GB(32)
> #define FRAMETABLE_SIZE        GB(32)
> #define FRAMETABLE_NR          (FRAMETABLE_SIZE / sizeof(*frame_table))
> -#define FRAMETABLE_VIRT_END    (FRAMETABLE_VIRT_START + FRAMETABLE_SIZE - 1)
> 
> #define DIRECTMAP_VIRT_START   SLOT0(256)
> #define DIRECTMAP_SIZE         (SLOT0_ENTRY_SIZE * (265-256))
> diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
> index 75e8adcfd6a1..57abc746e60b 100644
> --- a/xen/arch/arm/livepatch.c
> +++ b/xen/arch/arm/livepatch.c
> @@ -175,7 +175,7 @@ void __init arch_livepatch_init(void)
>     void *start, *end;
> 
>     start = (void *)LIVEPATCH_VMAP_START;
> -    end = (void *)LIVEPATCH_VMAP_END;
> +    end = start + LIVEPATCH_VMAP_SIZE;
> 
>     vm_init_type(VMAP_XEN, start, end);
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index be37176a4725..0607c65f95cd 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -128,9 +128,11 @@ static DEFINE_PAGE_TABLE(xen_first);
> /* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) 
> */
> static DEFINE_PER_CPU(lpae_t *, xen_pgtable);
> #define THIS_CPU_PGTABLE this_cpu(xen_pgtable)
> -/* xen_dommap == pages used by map_domain_page, these pages contain
> +/*
> + * xen_dommap == pages used by map_domain_page, these pages contain
>  * the second level pagetables which map the domheap region
> - * DOMHEAP_VIRT_START...DOMHEAP_VIRT_END in 2MB chunks. */
> + * starting at DOMHEAP_VIRT_START in 2MB chunks.
> + */

Please just mention that you also fixed a comment coding style in the commit 
message.

> static DEFINE_PER_CPU(lpae_t *, xen_dommap);
> /* Root of the trie for cpu0, other CPU's PTs are dynamically allocated */
> static DEFINE_PAGE_TABLE(cpu0_pgtable);
> @@ -476,7 +478,7 @@ mfn_t domain_page_map_to_mfn(const void *ptr)
>     int slot = (va - DOMHEAP_VIRT_START) >> SECOND_SHIFT;
>     unsigned long offset = (va>>THIRD_SHIFT) & XEN_PT_LPAE_ENTRY_MASK;
> 
> -    if ( va >= VMAP_VIRT_START && va < VMAP_VIRT_END )
> +    if ( (va >= VMAP_VIRT_START) && ((VMAP_VIRT_START - va) < 
> VMAP_VIRT_SIZE) )
>         return virt_to_mfn(va);
> 
>     ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
> @@ -570,7 +572,8 @@ void __init remove_early_mappings(void)
>     int rc;
> 
>     /* destroy the _PAGE_BLOCK mapping */
> -    rc = modify_xen_mappings(BOOT_FDT_VIRT_START, BOOT_FDT_VIRT_END,
> +    rc = modify_xen_mappings(BOOT_FDT_VIRT_START,
> +                             BOOT_FDT_VIRT_START + BOOT_FDT_VIRT_SIZE,
>                              _PAGE_BLOCK);
>     BUG_ON(rc);
> }
> @@ -850,7 +853,7 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t 
> pe)
> 
> void *__init arch_vmap_virt_end(void)
> {
> -    return (void *)VMAP_VIRT_END;
> +    return (void *)(VMAP_VIRT_START + VMAP_VIRT_SIZE);
> }
> 
> /*
> -- 
> 2.32.0
> 

Cheers
Bertrand




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.