Re: [Xen-devel] [PATCH v4 3/9] xen/arm: Implement set_memory_map hypercall for arm

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-10-04 at 13:43 +0900, Jaeyong Yoo wrote:
> From: Evgeny Fedotov <e.fedotov@xxxxxxxxxxx>
> 
> When creating domU in toolstack, pass the guest memory
> map info to the hypervisor, and the hypervisor stores those info in
> arch_domain for later use.
> 
> Singed-off-by: Evgeny Fedotov <e.fedotov@xxxxxxxxxxx>
> ---
>  tools/libxc/xc_dom_arm.c     | 12 +++++++-
>  tools/libxc/xc_domain.c      | 44 ++++++++++++++++++++++++++++
>  tools/libxc/xenctrl.h        | 23 +++++++++++++++
>  xen/arch/arm/domain.c        |  3 ++
>  xen/arch/arm/mm.c            | 68 
> ++++++++++++++++++++++++++++++++++++++++++++
>  xen/include/asm-arm/domain.h |  2 ++
>  xen/include/asm-arm/mm.h     |  1 +
>  xen/include/public/memory.h  | 15 ++++++++--
>  xen/include/xsm/dummy.h      |  5 ++++
>  xen/include/xsm/xsm.h        |  5 ++++
>  10 files changed, 175 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> index df59ffb..20c9095 100644
> --- a/tools/libxc/xc_dom_arm.c
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -166,6 +166,7 @@ int arch_setup_meminit(struct xc_dom_image *dom)
>  {
>      int rc;
>      xen_pfn_t pfn, allocsz, i;
> +    struct dt_mem_info memmap;
>  
>      dom->shadow_enabled = 1;
>  
> @@ -191,7 +192,16 @@ int arch_setup_meminit(struct xc_dom_image *dom)
>              0, 0, &dom->p2m_host[i]);
>      }
>  
> -    return 0;
> +    /* setup guest memory map */
> +    memmap.nr_banks = 2;
> +    memmap.bank[0].start = (dom->rambase_pfn << PAGE_SHIFT_ARM);
> +    memmap.bank[0].size = (dom->total_pages << PAGE_SHIFT_ARM);
> +    /*The end of main memory: magic pages */
> +    memmap.bank[1].start = memmap.bank[0].start + memmap.bank[0].size;
> +    memmap.bank[1].size = NR_MAGIC_PAGES << PAGE_SHIFT_ARM;

Are the 0 and 1 here hardcoded magic numbers?

> +    return xc_domain_set_memory_map(dom->xch, dom->guest_domid, &memmap);

I think this is using set_memory_map in a different way to it is used
for x86 (where it gives the PV e820 map, a PV version of a BIOS provided
datastructure).

The guest should get its memory map via DTB not via a PV hypercall. I
know the guest isn't using get_memory_map but I don't think we should
even make it available.

On x86 the magic pages are handled specially in the save restore code
via HVM_PARAMS and not exposed to the guest via this memory map call. I
think that's the way to go here too.

We do need a way to remember and return the guest RAM layout (well, for
now the RAM base is hardcoded, so we could fudge it) but I think a
toolstack internal mechanism like a save record would be better.

Ian.



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