Re: [PATCH v6 1/4] xen/riscv: add VM space layout

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.05.2023 18:31, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/config.h
> +++ b/xen/arch/riscv/include/asm/config.h
> @@ -4,6 +4,37 @@
>  #include <xen/const.h>
>  #include <xen/page-size.h>
>  
> +/*
> + * RISC-V64 Layout:
> + *
> + * From the riscv-privileged doc:
> + *   When mapping between narrower and wider addresses,
> + *   RISC-V zero-extends a narrower physical address to a wider size.
> + *   The mapping between 64-bit virtual addresses and the 39-bit usable
> + *   address space of Sv39 is not based on zero-extension but instead
> + *   follows an entrenched convention that allows an OS to use one or
> + *   a few of the most-significant bits of a full-size (64-bit) virtual
> + *   address to quickly distinguish user and supervisor address regions.
> + *
> + * It means that:
> + *   top VA bits are simply ignored for the purpose of translating to PA.
> + *
> + * 
> ============================================================================
> + *    Start addr    |   End addr        |  Size  | Slot       |area 
> description
> + * 
> ============================================================================
> + * FFFFFFFFC0000000 |  FFFFFFFFC0200000 |  2 MB  | L2 511     | Xen
> + * FFFFFFFFC0200000 |  FFFFFFFFC0600000 |  4 MB  | L2 511     | FDT
> + * FFFFFFFFC0600000 |  FFFFFFFFC0800000 |  2 MB  | L2 511     | Fixmap
> + *                 ...                  |  1 GB  | L2 510     | Unused
> + * 0000003200000000 |  0000007f40000000 | 331 GB | L2 200-609 | Direct map

I guess the upper value is 509 here?

> + *                 ...                  |  1 GB  | L2 199     | Unused
> + * 0000003100000000 |  0000003140000000 |  3 GB  | L2 196-198 | Frametable

The two leftmost columns cover 1Gb only.

> + *                 ...                  |  1 GB  | L2 195     | Unused
> + * 0000003080000000 |  00000030c0000000 |  1 GB  | L2 194     | VMAP
> + *     .................. unused ..................
> + * 
> ============================================================================
> + */

Two more remarks: This map is, aiui, Sv39-specific. The quotation from the
doc doesn't really imply that, so I'd suggest to add something to make this
explicit. This might be as simple as a suitable #ifdef around or inside
the comment (even inside I think it'll be easily understood what it means;
see e.g. the CONFIG_BIGMEM conditional in x86'es table).

The other oddity here is the sorting of entries: You sort downwards by L2
slot, but upwards within slot 511. Once suitably re-ordered it'll become
apparent that there's another "unused" row missing (or perhaps even two).

Jan