Re: [Patch V5 13/16] xen: add explicit memblock_reserve() calls for special pages

From: Juergen Gross
Date: Mon Jul 13 2015 - 00:10:33 EST


On 07/10/2015 03:36 PM, Konrad Rzeszutek Wilk wrote:
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 1982617..c28f7f7 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2084,6 +2084,19 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, unsigned long max_pfn)
}
#endif /* CONFIG_X86_64 */

+void __init xen_reserve_special_pages(void)
+{
+ phys_addr_t paddr;
+
+ memblock_reserve(__pa(xen_start_info), PAGE_SIZE);
+ if (!xen_initial_domain()) {
+ paddr = PFN_PHYS(mfn_to_pfn(xen_start_info->store_mfn));
+ memblock_reserve(paddr, PAGE_SIZE);
+ paddr = PFN_PHYS(mfn_to_pfn(xen_start_info->console.domU.mfn));
+ memblock_reserve(paddr, PAGE_SIZE);
+ }

I believe we can start an MiniOS as the 'dom0' (so first domain), and then
Linux right after as the 'dom1' (semi-dom0?). In which case XenStore would
be actually available.

And this dom1 would still be the "initial domain" (SIF_INITDOMAIN set)?

I couldn't spot other Xen usage of this flag as the one in the
hypervisor when constructing the "real" initial domain.

Is there an way to figure out whether these mfns are valid and just
piggyback on that?

For store_mfn: yes (it's initialized to 0 by the hypervisor).

The console mfn: no, as the console info is a union which will hold
different information in case of the initial domain.


Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/