Re: [RFC 1/2] xen/mm: Clarify the granularity for each Frame Number

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 05/08/15 12:28, Julien Grall wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> ARM64 is able to support 64KB and 4KB page granularities. While the guest
> will support both granularities, Xen and hypercall interface will always
> be in 4KB.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@citrix.com>
> Signed-off-by: Julien Grall <julien.grall@citrix.com>
>
> ---
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Tim Deegan <tim@xen.org>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>
> I'm missing one term for Linux Frame Number but always in 4KB
> granularity. It's necessary in few places such as the balloon code where
> we need to map a Linux 4KB Frame Number into a Machine Frame Number.
>
> I was thinking to name it xen_pfn.
> ---
>  xen/include/xen/mm.h | 20 ++++++++++++++------
>  1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
> index 876d370..8dfd61a 100644
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -15,16 +15,24 @@
>   *
>   * mfn: Machine Frame Number
>   *   The values Xen puts into its own pagetables.  This is the host physical
> - *   memory address space with RAM, MMIO etc.
> + *   memory address space with RAM, MMIO etc. Always 4KB granularity.
>   *
>   * gfn: Guest Frame Number
> - *   The values a guest puts in its own pagetables.  For an auto-translated
> - *   guest (hardware assisted with 2nd stage translation, or shadowed), gfn !=
> - *   mfn.  For a non-translated guest which is aware of Xen, gfn == mfn.
> + *   The values a guest puts in its own pagetables, except for 64KB
> + *   granularity. Gfns are always based on 4KB granularity, while actually
> + *   the guest could use other granularities.  For an auto-translated guest
> + *   (hardware assisted with 2nd stage translation, or shadowed), gfn != mfn.
> + *   For a non-translated guest which is aware of Xen, gfn == mfn.
> + *   Hypercalls take gfns, not mfns, as parameters unless clearly specified
> + *   otherwise.
>   *
>   * pfn: Pseudophysical Frame Number
> - *   A linear idea of a guest physical address space. For an auto-translated
> - *   guest, pfn == gfn while for a non-translated guest, pfn != gfn.
> + *   A linear idea of a guest physical address space. Pfns are in guest
> + *   granularity, which can be 64KB or 4KB. PV guests must only use 4KB
> + *   granularity. For an auto-translated guest, pfn == gfn << shift,
> + *   where the shift is the different between the Xen and Linux page
> + *   granularity, while for a non-translated guest, pfn != gfn. Pfns are
> + *   internal to the guest and are not passed to hypercalls.
>   *
>   * WARNING: Some of these terms have changed over time while others have been
>   * used inconsistently, meaning that a lot of existing code does not match the

I am not certain whether this is relevant information in these locations
specifically.  These descriptions are for the address spaces themselves,
rather than for the representations therewithin.

64K granularity is also similar to 2M/1G superpages in their handling,
the difference being that 64K can't be subdivided if necessary?

I think a section about granularity is worthwhile, but probably a
separate paragraph.  I think it is also worth keeping Xen's idea of
memory all at 4K, and in cases where 64K is in use, require appropriate
alignment in the parameter.

~Andrew