Re: [Xen-devel] [PATCH V4] Add flag to start info regarding virtual mapped p2m list

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-03-18 at 16:28 +0100, Juergen Gross wrote:
> Xen pv domains are using a domain private p2m list to convert guest pfns
> to mfns. This p2m list has to be updated by the Xen tools during domain
> restore and migration, as the mfns will most likely change. In order to
> locate the p2m list the Xen tools need an interface provided by the
> guest. Up to now this interface has been the shared info page where the
> guest would store the mfn of the top level page of a 3-level p2m tree.
> 
> This p2m tree is fixed in it's layout and due to the limitation of
> entries it can hold at each level it is limiting the maximum size of the
> p2m list which can be reported to the Xen tools. The maximum memory the
> p2m tree can support for 64 bit domains is 512 GB (32 bit domains don't
> have a problem, as the p2m tree limit is much higher than the supported
> domain size of 64 GB).
> 
> In order to be able to support pv domains with more than 512 GB an
> additional way to specify the p2m list for the Xen tools has been added:
> instead of a tree structure linked via mfns, the virtual address of a
> linear p2m list, the cr3 value of the related address space and the size
> of the p2m list can be specified by the guest (added by commit
> 50bd1f0825339dfacde471df7664729216fc46e3).
> 
> Guests implementing this new interface need to know, of course, whether
> the Xen tools are capable to use the new interface instead of the old
> p2m tree interface. Otherwise a guest using only the new interface with
> the virtual mapped linear p2m list on a machine with old Xen tools not
> supporting this interface could not be restored or migrated.
> 
> The added flag in the start info indicates the Xen tool's capability to
> use the new interface enabling the guest to omit the p2m tree and thus
> to support more than 512 GB of RAM.

Thanks, other than the ongoing concerns about memory hotplug this looks
ok to me now (except the name sucks, but there's been enough
bike-shedding of that already).

> 
> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> ---
>  xen/include/public/xen.h | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 3703c39..66c09a3 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -773,10 +773,12 @@ typedef struct start_info start_info_t;
>  #endif /* XEN_HAVE_PV_GUEST_ENTRY */
>  
>  /* These flags are passed in the 'flags' field of start_info_t. */
> -#define SIF_PRIVILEGED    (1<<0)  /* Is the domain privileged? */
> -#define SIF_INITDOMAIN    (1<<1)  /* Is this the initial control domain? */
> -#define SIF_MULTIBOOT_MOD (1<<2)  /* Is mod_start a multiboot module? */
> -#define SIF_MOD_START_PFN (1<<3)  /* Is mod_start a PFN? */
> +#define SIF_PRIVILEGED      (1<<0)  /* Is the domain privileged? */
> +#define SIF_INITDOMAIN      (1<<1)  /* Is this the initial control domain? */
> +#define SIF_MULTIBOOT_MOD   (1<<2)  /* Is mod_start a multiboot module? */
> +#define SIF_MOD_START_PFN   (1<<3)  /* Is mod_start a PFN? */
> +#define SIF_VIRT_P2M_4TOOLS (1<<4)  /* Do Xen tools understand a virt. 
> mapped */
> +                                    /* P->M making the 3 level tree 
> obsolete? */
>  #define SIF_PM_MASK       (0xFF<<8) /* reserve 1 byte for xen-pm options */
>  
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel