From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: RFC: QEMU bumping memory limit and domain restore Date: Tue, 2 Jun 2015 17:11:02 +0100 Message-ID: <556DD596.5000008@citrix.com> References: <20150602140507.GM19403@zion.uk.xensource.com> <20150602140806.GN19403@zion.uk.xensource.com> <1433260149.15036.333.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yzopx-0001Ej-1I for xen-devel@lists.xenproject.org; Tue, 02 Jun 2015 16:14:45 +0000 In-Reply-To: <1433260149.15036.333.camel@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: Ian Campbell , Wei Liu Cc: xen-devel@lists.xenproject.org, yanghy@cn.fujitsu.com, Ian Jackson , dslutz@verizon.com, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 02/06/15 16:49, Ian Campbell wrote: > On Tue, 2015-06-02 at 15:08 +0100, Wei Liu wrote: > [...] >>> So here is a proof of concept patch to record and honour that value >>> during migration. A new field is added in IDL. Note that we don't >>> provide xl level config option for it and mandate it to be default value >>> during domain creation. This is to prevent libxl user from using it to >>> avoid unforeseen repercussions. >> [...] >>> This field is mandated to be default value during guest creation to >>> avoid unforeseen repercussions. It's only honour when restoring a guest. > IMHO this means that the libxl API/IDL is the wrong place for this > value. Only user and/or application serviceable parts belong in the API. > > So while I agree that this value need to be communicated across a > migration, the JSON blob is not the right mechanism for doing so. IOW if > you go down this general path I think you need a new > field/record/whatever in the migration protocol at some layer or other > (if not libxc then at the libxl layer). > > To my mind this "actual state" vs "user configured state" is more akin > to the sorts of things which is in the hypervisor save blob or something > like that (nb: This is not a suggestion that it should go there). > > IIRC Don also outlined another case, which is > xl create -p > xl migrate > xl unpause > > Which might need more thought if any bumping can happen after the > migrate i.e. on unpause? > > The problem is qemu using set_max_mem. It should never have done so. Nothing other than libxl should be using such hypercalls, at which point libxls idea of guest memory is accurate and the bug ceases to exist. ~Andrew