Re: [Xen-devel] [PATCH RESEND v5 2/6] xen/arm: Implement get_maximum_gpfn hypercall for arm

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-11-08 at 16:50 +0900, Jaeyong Yoo wrote:
> From: Evgeny Fedotov <e.fedotov@xxxxxxxxxxx>
> 
> By using the memory map info in arch_domain (from set_memory_map hypercall)
> implement get_maximum_gpfn hypercall.
> 
> Changes from v4: Use GUEST_RAM_BASE as the start physical address of guest
> RAM. And, purge set-memory-map patch
> 
> Singed-off-by: Evgeny Fedotov <e.fedotov@xxxxxxxxxxx>
> ---
>  xen/arch/arm/mm.c        | 22 +++++++++++++++++++++-
>  xen/include/asm-arm/mm.h |  2 ++
>  2 files changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 123280e..3801f07 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -927,7 +927,11 @@ int page_is_ram_type(unsigned long mfn, unsigned long 
> mem_type)
>  
>  unsigned long domain_get_maximum_gpfn(struct domain *d)

s/unsigned long/xen_pfn_t/ I think.

Urk, which will break the ABI for this hypercall. That's something of a
conundrum :-/

It is a domctl so we are at liberty to change it, probably to taking a
xen_pfn_t * to fill in instead of returning the value.

I'm in two minds about whether we should do so now or postpone it (which
risks forgetting and having an obscure bug somewhere down the line).

>  {
> -    return -ENOSYS;
> +    paddr_t end;
> +
> +    get_gma_start_end(d, NULL, &end);

I suppose this function is useful in a future patch too, otherwise 
        return (GUEST_RAM_BASE>>PAGE_SHIFT)+d->max_pages
would suffice.

Ian.


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