[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 3/9] xen/arm: Implement set_memory_map hypercall for arm
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |