[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

12.11.2013 19:21, Ian Campbell ÐÐÑÐÑ:
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 
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).
OK, this way, or other solution is to purge this hypercall yet in migration and use max_memkb field in DOMCTL_getdomaininfo to obtain the maximum PFN.

-    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.

Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.