From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugene Fedotov Subject: Re: [PATCH v4 3/9] xen/arm: Implement set_memory_map hypercall for arm Date: Fri, 11 Oct 2013 14:06:35 +0400 Message-ID: <5257CDAB.4060205@samsung.com> References: <1380861845-23268-1-git-send-email-jaeyong.yoo@samsung.com> <1380861845-23268-4-git-send-email-jaeyong.yoo@samsung.com> <1381402597.17758.3.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <1381402597.17758.3.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 10.10.2013 14:56, Ian Campbell: > On Fri, 2013-10-04 at 13:43 +0900, Jaeyong Yoo wrote: >> From: Evgeny Fedotov >> >> 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 >> --- >> 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? Well, we hardcoded here two memory regions: the first one for RAM, the second one for "magic pages". >> + 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). Do you mean that using e820 structure for ARM implementation is better than dt_mem_info structure (that has been taken from libdt) and should be used in ARM implementation of get/set memory map? > 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. OK, this hypercall will be available from dom0 only. > > 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. > So, get/set memory map hypercall should get/set only main RAM region? Two questions about details of next implementation: 1) Can we restrict memory map number of regions to 1 for ARM? In this case we don't need list or array to define memory map structure. 2)We have already implemented store& restore of HVM params (magic pages PFNs) inside ARM toolstack, but I don't know if we need to migrate contents of such pages. In current ARM toolstack we migrate magic pages contents too as a part of memory map. In x86 code I cannot find where the content of magic pages are saved or restored, so may be Xen developers are familiar about it. Best regards, Eugene.