From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNEIZ-00006r-BU for qemu-devel@nongnu.org; Sun, 24 Jan 2016 01:37:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNEIW-0004b7-5Y for qemu-devel@nongnu.org; Sun, 24 Jan 2016 01:37:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNEIV-0004b3-Vz for qemu-devel@nongnu.org; Sun, 24 Jan 2016 01:37:16 -0500 Date: Sun, 24 Jan 2016 08:37:12 +0200 From: "Michael S. Tsirkin" Message-ID: <20160124083526-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> <1453459914.17005.16.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1453459914.17005.16.camel@redhat.com> 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: Gerd Hoffmann Cc: Eduardo Habkost , qemu-devel@nongnu.org, Paolo Bonzini , Richard Henderson On Fri, Jan 22, 2016 at 11:51:54AM +0100, Gerd Hoffmann wrote: > 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. > > > > > > I doubt this simplified things, given the backward compatibility > > > constrains we have. > > > > > > cheers, > > > Gerd > > > > 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. Yes we don't want that. I was vaguely thinking some kind of query that reports the required info so management just has to maintain that. > 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 I'd like to gather some feedback from management folk first. -- MST