From owner-freebsd-xen@FreeBSD.ORG Tue Dec 24 11:22:38 2013 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27E083EA; Tue, 24 Dec 2013 11:22:38 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8CCA71670; Tue, 24 Dec 2013 11:22:35 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,542,1384300800"; d="scan'208";a="87481875" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 24 Dec 2013 11:22:27 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Tue, 24 Dec 2013 06:22:26 -0500 Received: from gateway-cbg.eng.citrite.net ([10.80.16.17] helo=localhost.localdomain) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1VvQ4A-0007qS-Uf; Tue, 24 Dec 2013 11:22:27 +0000 From: Roger Pau Monne To: , , , , , , Subject: [PATCH RFC 01/13] xen: use the hardware e820 map on Dom0 Date: Tue, 24 Dec 2013 12:20:50 +0100 Message-ID: <1387884062-41154-2-git-send-email-roger.pau@citrix.com> X-Mailer: git-send-email 1.7.7.5 (Apple Git-26) In-Reply-To: <1387884062-41154-1-git-send-email-roger.pau@citrix.com> References: <1387884062-41154-1-git-send-email-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain X-DLP: MIA2 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 11:22:38 -0000 We need to do some tweaking of the hardware e820 map, since the memory layout provided by Xen and the e820 map doesn't match. This consists in clamping the e820 map so that regions above max_pfn are marked as unusuable. --- sys/x86/xen/pv.c | 35 +++++++++++++++++++++++++++++++++-- 1 files changed, 33 insertions(+), 2 deletions(-) diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c index 4f7415e..ab4afba 100644 --- a/sys/x86/xen/pv.c +++ b/sys/x86/xen/pv.c @@ -297,17 +297,48 @@ static void xen_pv_parse_memmap(caddr_t kmdp, vm_paddr_t *physmap, int *physmap_idx) { struct xen_memory_map memmap; + unsigned long max_pfn = HYPERVISOR_start_info->nr_pages; + u_int64_t mem_end = ptoa(max_pfn); u_int32_t size; - int rc; + int rc, mem_op, i; /* Fetch the E820 map from Xen */ memmap.nr_entries = MAX_E820_ENTRIES; set_xen_guest_handle(memmap.buffer, xen_smap); - rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap); + mem_op = xen_initial_domain() ? + XENMEM_machine_memory_map : + XENMEM_memory_map; + rc = HYPERVISOR_memory_op(mem_op, &memmap); if (rc) panic("unable to fetch Xen E820 memory map"); size = memmap.nr_entries * sizeof(xen_smap[0]); + /* + * This should be improved, Xen provides us with a single + * chunk of physical memory that goes from 0 to max_pfn, + * and what we do here is clamp the HW memory map to make + * sure regions above max_pfn are marked as reserved. + * + * TRTTD would be to move the memory not used because of + * the holes in the HW memory map to the now clamped regions + * using XENMEM_{decrease/increase}_reservation. + */ + for (i = 0; i < memmap.nr_entries; i++) { + u_int64_t end = xen_smap[i].base + xen_smap[i].length; + if (xen_smap[i].type == SMAP_TYPE_MEMORY) { + if (xen_smap[i].base > mem_end) { + /* Mark as reserved */ + xen_smap[i].type = SMAP_TYPE_RESERVED; + continue; + } + if (end > mem_end) { + /* Truncate region */ + xen_smap[i].length -= end - mem_end; + } + } + } + + bios_add_smap_entries(xen_smap, size, physmap, physmap_idx); } -- 1.7.7.5 (Apple Git-26)