Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752700AbdGHBAM (ORCPT ); Fri, 7 Jul 2017 21:00:12 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:48524 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751751AbdGHBAL (ORCPT ); Fri, 7 Jul 2017 21:00:11 -0400 Date: Fri, 7 Jul 2017 20:59:58 -0400 From: Konrad Rzeszutek Wilk To: Juergen Gross Cc: Boris Ostrovsky , Jan Beulich , Dan Streetman , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages" Message-ID: <20170708005958.GA30785@char.us.oracle.com> References: <0628e2af-f7e7-056a-82ec-68860f9c4f29@oracle.com> <20170324211016.GG9755@char.us.oracle.com> <9b134234-5b38-c325-b3c2-f37b4c45c2cf@oracle.com> <58DA361E0200007800148E16@prv-mh.provo.novell.com> <2288a326-752e-85a5-d986-62c86b91e249@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1864 Lines: 39 On Tue, Mar 28, 2017 at 05:30:24PM +0200, Juergen Gross wrote: > On 28/03/17 16:27, Boris Ostrovsky wrote: > > On 03/28/2017 04:08 AM, Jan Beulich wrote: > >>>>> On 28.03.17 at 03:57, wrote: > >>> I think there is indeed a disconnect between target memory (provided by > >>> the toolstack) and current memory (i.e actual pages available to the guest). > >>> > >>> For example > >>> > >>> [ 0.000000] BIOS-e820: [mem 0x000000000009e000-0x000000000009ffff] > >>> reserved > >>> [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] > >>> reserved > >>> > >>> are missed in target calculation. The hvmloader marks them as RESERVED > >>> (in build_e820_table()) but target value is not aware of this action. > >>> > >>> And then the same problem repeats when kernel removes > >>> 0x000a0000-0x000fffff chunk. > >> But this is all in-guest behavior, i.e. nothing an entity outside the > >> guest (tool stack or hypervisor) should need to be aware of. That > >> said, there is still room for improvement in the tools I think: > >> Regions which architecturally aren't RAM (namely the > >> 0xa0000-0xfffff range) would probably better not be accounted > >> for as RAM as far as ballooning is concerned. In the hypervisor, > >> otoh, all memory assigned to the guest (i.e. including such backing > >> ROMs) needs to be accounted. > > > > On the Linux side we should not include in balloon calculations pages > > reserved by trim_bios_range(), i.e. (BIOS_END-BIOS_BEGIN) + 1. > > > > Which leaves hvmloader's special pages (and possibly memory under > > 0xA0000 which may get reserved). Can we pass this info to guests via > > xenstore? > > I'd rather keep an internal difference between online pages and E820-map > count value in the balloon driver. This should work always. Did we ever come with a patch for this?