From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory Date: Tue, 14 Apr 2015 13:34:43 -0400 Message-ID: <552D4FB3.9060109@one.verizon.com> References: <1428941353-18673-1-git-send-email-dslutz@verizon.com> <552BEDF1.7070209@citrix.com> <552C5683.1040903@one.verizon.com> <20150414085304.GM17670@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150414085304.GM17670@zion.uk.xensource.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: Wei Liu Cc: Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , "xen-devel@lists.xen.org" , Shriram Rajagopalan , Yang Hongyang List-Id: xen-devel@lists.xenproject.org On 04/14/15 04:53, Wei Liu wrote: > On Mon, Apr 13, 2015 at 07:51:31PM -0400, Don Slutz wrote: >> On 04/13/15 12:25, Andrew Cooper wrote: >>> On 13/04/15 17:09, Don Slutz wrote: >>>> If QEMU has called on xc_domain_setmaxmem to add more memory for >>>> option ROMs, domain restore needs to also increase the memory. >>>> >>>> Signed-off-by: Don Slutz >>> hvmloader has no interaction with xc_domain_restore(). >> I did not mean to imply that it did. Somehow I lost the fact that this >> is a bug in master: >> >> [root@dcs-xen-52 don]# xl cre -p /home/don/e1000x8.xfg >> The page data is correctly saved into the save file (migration stream). >> However when >> the new domain is created, it's size is "wrong". You cannot adjust any >> of the config info to fix the size, because the option ROM space to >> reserve is not an existing config option. So if I am following you >> correctly, libxl needs to add and process more info to handle this case. >> > Thanks for the analysis. I think what you need to do is to adjust the > memory size during domain creation in libxl, then the relevant data is > saved at creation time. It should not be modified during restore. > > There is already various adjustments to memory related values in libxl. > Grep video_memkb and mex_memkb in libxl. I am assuming you mean max_memkb (since I cannot find mex_memkb). And it has the "hack" adjustment of "max_memkb + LIBXL_MAXMEM_CONSTANT". > Is there a way to know how much more memory each option rom needs? If > so, you can correctly account for the extra memory you need. This would > be an ideal fix to this problem. I do not know of a way to get this info. It can change based on the QEMU version. The static define: tools/libxl/libxl_internal.h:#define LIBXL_MAXMEM_CONSTANT 1024 Is the the old xl "hack" that allows Xen 4.5 (and before) to support up to 4 e1000 nics. -Don Slutz > Wei. > >>> The migration path should not be hacked up to fix a higher level >>> toolstack bug. >> I do not see how QEMU is part of the "higher level toolstack". If you >> mean xl vs xc, then >> I can see "xl save" some how doing the work. This patch works for me, >> but I am happy to >> explore other ways to fix this bug. >> >> -Don Slutz >> >>> ~Andrew