From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMZJz-0004ti-5d for qemu-devel@nongnu.org; Fri, 22 Jan 2016 05:52:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMZJw-0004jU-01 for qemu-devel@nongnu.org; Fri, 22 Jan 2016 05:52:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMZJv-0004jM-RB for qemu-devel@nongnu.org; Fri, 22 Jan 2016 05:51:59 -0500 Message-ID: <1453459914.17005.16.camel@redhat.com> From: Gerd Hoffmann Date: Fri, 22 Jan 2016 11:51:54 +0100 In-Reply-To: <20160121113307-mutt-send-email-mst@redhat.com> References: <1452257883-19549-1-git-send-email-kraxel@redhat.com> <20160119123739.GA27855@thinpad.lan.raisama.net> <1453301733.11804.142.camel@redhat.com> <20160120153429.GA4218@thinpad.lan.raisama.net> <20160120171504.GB4218@thinpad.lan.raisama.net> <20160120192229-mutt-send-email-mst@redhat.com> <1453362533.11655.26.camel@redhat.com> <20160121113307-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v2] pc: allow raising low memory via max-ram-below-4g option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Eduardo Habkost , qemu-devel@nongnu.org, Paolo Bonzini , Richard Henderson Hi, > > > I wonder whether we should just bite the bullet and ask management to > > > maintain the physical memory map for us, instead of trying to give us > > > hints. > >=20 > > I doubt this simplified things, given the backward compatibility > > constrains we have. > >=20 > > cheers, > > Gerd >=20 > That's exactly what would become simple. > For backwards compatibility we would leave things alone > if the new flags for the memory map aren't specified. But we'll add a bunch of new code for the new config mode which allows management to maintain the physical memory map. And we'll expect management know about a bunch of machine type internals. That isn't a simplification. > This would allow people to e.g. allocate phy address > ranges for things like nvdimm which has been > problematic in the past. Didn't follow nvdimm discussions. If you think we really need that anyway to solve certain issues, sure, go ahead and I happily adjust this patch to use the new infrastructure. cheers, Gerd