[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [PATCH 05/10] xen/setup: Set identity mapping for non-RAM E820 and E820 gaps.
> Couldn't you just do something like: > > if (e820->map[i].type != E820_RAM) I am going to assume you meant '==' here. > continue; > > for (pfn = PFN_UP(last); pfn < PFN_DOWN(start); pfn++) > set_phys_to_machine(pfn, pfn); > identity += pfn - PFN_UP(last); > > last = end; > > ie, handle the hole and non-RAM cases together? A derivation of this does work: last = ISA_END_ADDRESS; for (i = 0; i < e820->nr_map; i++) { phys_addr_t start = e820->map[i].addr; phys_addr_t end = start + e820->map[i].size; if (end < start) continue; /* Skip over the 1MB region. */ if (last > end) continue; if (e820->map[i].type == E820_RAM) { /* Without saving 'last' we would end up gobbling RAM regions. */ last = end; continue; } for (pfn = PFN_UP(last); pfn < PFN_DOWN(end); pfn++) set_phys_to_machine(pfn, pfn); identity += pfn - PFN_UP(last); last = end; } > > Also, what happens with the p2m tree mid layers in this? If you're > doing page-by-page set_phys_to_machine, won't it end up allocating them > all? How can you optimise the "large chunks of address space are > identity" case? The issue here is that when this code path is called (xen_memory_setup), the p2m_top[topidx][mididx] has been set to start_info->mfn_list[] (by xen_build_dynamic_phys_to_machine). Granted, some of these entries have been evicted (by the xen_return_unused_memory), so the regions in the mfn_list are pock-marked with INVALID_P2M_ENTRY. For those regions we set the PFN in the p2m_top[topidx][mididx][idx]. We do not allocate anything during this pass. In the the dom0_mem=max:X (or X,max:Y, where Y>X), which I neglected to test this would actually try to allocate (whoops). Let me roll up a patch for this. > > It would probably be cleanest to have a set_ident_phys_to_machine(start, > end) function which can do all that. Not sure if it is truly needed. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |