From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory Date: Thu, 16 Apr 2015 10:29:15 +0100 Message-ID: <1429176555.25195.56.camel@citrix.com> References: <552CD5A7.4080803@citrix.com> <552CDC57.1020107@cn.fujitsu.com> <20150414092937.GO17670@zion.uk.xensource.com> <552CE088.1060401@cn.fujitsu.com> <20150414095221.GR17670@zion.uk.xensource.com> <552D51CA.9040209@one.verizon.com> <20150414175437.GB11717@zion.uk.xensource.com> <1429108488.15516.303.camel@citrix.com> <20150415163612.GB29894@zion.uk.xensource.com> <1429116315.25195.24.camel@citrix.com> <20150415165231.GD29894@zion.uk.xensource.com> <1429174806.25195.41.camel@citrix.com> <552F7D8B.7010907@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <552F7D8B.7010907@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Wei Liu , Stefano Stabellini , Andrew Cooper , Ian Jackson , Don Slutz , "xen-devel@lists.xen.org" , Shriram Rajagopalan , Hongyang Yang List-Id: xen-devel@lists.xenproject.org On Thu, 2015-04-16 at 10:14 +0100, George Dunlap wrote: > On 04/16/2015 10:00 AM, Ian Campbell wrote: > > On Wed, 2015-04-15 at 17:52 +0100, Wei Liu wrote: > >> On Wed, Apr 15, 2015 at 05:45:15PM +0100, Ian Campbell wrote: > >>> On Wed, 2015-04-15 at 17:36 +0100, Wei Liu wrote: > >>>> On Wed, Apr 15, 2015 at 03:34:48PM +0100, Ian Campbell wrote: > >>>>> On Tue, 2015-04-14 at 18:54 +0100, Wei Liu wrote: > >>>>>> Let's see if we can record this in xc image format. I haven't looked, > >>>>>> but George mentioned that it might be possible to do so. > >>>>> > >>>>> Can this not be done at the save stage in the bit where we update the > >>>>> JSON to reflect the actual configuration? > >>>>> > >>>> > >>>> Yes, it's possible to do that. The value is not in libxl idl simply > >>>> because it's always not there. > >>> > >>> We can't set the existing maxmem then? > >>> > >> > >> If the "we" in your question means an applications that use libxl's > >> public interface, then no. It's not in IDL. It's not in xenstore. That > >> value is currently managed by libxl + libxc + xen. > > > > I was thinking of libxl_domain_build_info.max_memkb, which is in a > > struct which is marshalled over the wire and which could be updated on > > save to reflect the actual usage. > > > > Does using that field not work for some reason? > > The problem, I think, is that max_memkb says how much memory is > *reported to the guest*. So what happens when the VM on the other side > reboots? Won't libxl use this newly-increased max_memkb as the memory > to be reported *to the guest*? And then qemu will have to allocate *yet > more* memory for its roms? Ah, yes, I think you are right, that's pretty dumb. > Meaning that the size of the VM will increase by a few kB (MB?) every > time it reboots? > > This is why I think we should try to start making a clear distinction > between "what the guest sees as RAM" and "what xen sees as memory"; And > I proposed using "memory" for what the guest sees, and "pages" for what > Xen sees. That might help, as might my remembering about docs/misc/libxl_memory.txt more often. Ian.