From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwZFP-00084g-Rg for qemu-devel@nongnu.org; Thu, 04 Dec 2014 11:27:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwZFJ-0001TD-Nx for qemu-devel@nongnu.org; Thu, 04 Dec 2014 11:27:19 -0500 Received: from omzsmtpe04.verizonbusiness.com ([199.249.25.207]:18249) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwZFJ-0001T6-Go for qemu-devel@nongnu.org; Thu, 04 Dec 2014 11:27:13 -0500 From: Don Slutz Message-ID: <54808B52.8010603@terremark.com> Date: Thu, 04 Dec 2014 11:26:58 -0500 MIME-Version: 1.0 References: <5474C96A.6090506@citrix.com> <54768F7F.2030602@terremark.com> <547C6E12.50502@terremark.com> <547CF6C6.4060106@terremark.com> <547E1FC1.70004@terremark.com> <20141203105458.GA4208@zion.uk.xensource.com> <547F1274.6090607@terremark.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] increase maxmem before calling xc_domain_populate_physmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini , Don Slutz Cc: Andrew Cooper , xen-devel@lists.xensource.com, Wei Liu , Ian Campbell , qemu-devel@nongnu.org On 12/03/14 09:50, Stefano Stabellini wrote: > On Wed, 3 Dec 2014, Don Slutz wrote: >> On 12/03/14 07:20, Stefano Stabellini wrote: >>> On Wed, 3 Dec 2014, Wei Liu wrote: >>>> On Tue, Dec 02, 2014 at 03:23:29PM -0500, Don Slutz wrote: >>>> [...] >>>>>>>>> hw_error("xc_domain_getinfo failed"); >>>>>>>>> } >>>>>>>>> - if (xc_domain_setmaxmem(xen_xc, xen_domid, info.max_memkb + >>>>>>>>> - (nr_pfn * XC_PAGE_SIZE / 1024)) < >>>>>>>>> 0) { >>>>>>>>> + max_pages = info.max_memkb * 1024 / XC_PAGE_SIZE; >>>>>>>>> + free_pages = max_pages - info.nr_pages; >>>>>>>>> + real_free = free_pages; >>>>>>>>> + if (free_pages > VGA_HOLE_SIZE) { >>>>>>>>> + free_pages -= VGA_HOLE_SIZE; >>>>>>>>> + } else { >>>>>>>>> + free_pages = 0; >>>>>>>>> + } >>>>>> I don't think we need to subtract VGA_HOLE_SIZE. >>>>> If you do not use some slack (like 32 here), xen does report: >>>>> >>>>> >>>>> (d5) [2014-11-29 17:07:21] Loaded SeaBIOS >>>>> (d5) [2014-11-29 17:07:21] Creating MP tables ... >>>>> (d5) [2014-11-29 17:07:21] Loading ACPI ... >>>>> (XEN) [2014-11-29 17:07:21] page_alloc.c:1568:d5 Over-allocation for >>>>> domain >>>>> 5: 1057417 > 1057416 >>>>> (XEN) [2014-11-29 17:07:21] memory.c:158:d5 Could not allocate order=0 >>>> This message is a bit red herring. >>>> >>>> It's hvmloader trying to populate ram for firmware data. The actual >>>> amount of extra pages needed depends on the firmware. >>>> >>>> In any case it's safe to disallow hvmloader from doing so, it will just >>>> relocate some pages from ram (hence shrinking *mem_end). >>> That looks like a better solution >>> >> I went with a "leave some slack" so that the error message above is not >> output. >> >> When a change to hvmloader is done so that the message does not appear during >> normal usage, the extra pages in QEMU can be dropped. > Although those messages look like fatal errors, they are not. It is > normal way for hvmloader to operate: firstly it tries to allocate extra > memory until it gets an error, then it continues with normal memory, > see: > > void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns) > { > static int over_allocated; > struct xen_add_to_physmap xatp; > struct xen_memory_reservation xmr; > > for ( ; nr_mfns-- != 0; mfn++ ) > { > /* Try to allocate a brand new page in the reserved area. */ > if ( !over_allocated ) > { > xmr.domid = DOMID_SELF; > xmr.mem_flags = 0; > xmr.extent_order = 0; > xmr.nr_extents = 1; > set_xen_guest_handle(xmr.extent_start, &mfn); > if ( hypercall_memory_op(XENMEM_populate_physmap, &xmr) == 1 ) > continue; > over_allocated = 1; > } > > /* Otherwise, relocate a page from the ordinary RAM map. */ > > I think there is really nothing to change there. Maybe we want to make > those warnings less scary. It was not so much that hvmloader is the one to change (but having it check for room first might be good), but more that a change to xen would be good (like changing the wording or maybe only output in debug=y builds, etc.). Maybe a new XENMEMF to suppress the message? -Don Slutz