From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: BUG: failed to save x86 HVM guest with 1TB ram Date: Wed, 9 Sep 2015 19:50:49 +0100 Message-ID: <55F07F89.7040008@citrix.com> References: <8ADDA2EB7601DA429B6B2A43EF4620A51D9345E8@szxeml556-mbs.china.huawei.com> <55ED5D76.9030808@citrix.com> <8ADDA2EB7601DA429B6B2A43EF4620A51D934F45@szxeml556-mbs.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZZkSK-0002qj-ML for xen-devel@lists.xenproject.org; Wed, 09 Sep 2015 18:50:52 +0000 In-Reply-To: <8ADDA2EB7601DA429B6B2A43EF4620A51D934F45@szxeml556-mbs.china.huawei.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: "wangxin (U)" , "xen-devel@lists.xenproject.org" Cc: Fanhenglong , "wei.liu2@citrix.com" , "Hanweidong (Randy)" List-Id: xen-devel@lists.xenproject.org On 08/09/15 03:28, wangxin (U) wrote: > >> The check serves a dual purpose. In the legacy case, it is to avoid >> clobbering the upper bits of pfn information with pfn type information >> for 32bit toolstacks; any PFN above 2^28 would have type information >> clobbering the upper bits. This has been mitigated somewhat in >> migration v2, as pfns are strictly 64bit values, still using the upper 4 >> bits for type information, allowing 60 bits for the PFN itself. >> >> The second purpose is just as a limit on toolstack resources. Migration >> requires allocating structures which scale linearly with the size of the >> VM; the biggest of which would be ~1GB for the p2m. Added to this is >> >1GB for the m2p, and suddenly a 32bit toolstack process is looking >> scarce on RAM. >> >> During the development of migration v2, I didn't spend any time >> considering if or how much it was sensible to lift the restriction by, >> so the check was imported wholesale from the legacy code. >> >> For now, I am going to say that it simply doesn't work. Simply upping >> the limit is only a stopgap measure; an HVM guest can still mess this up > Will the stopgap measure work in xen 4.5? I don't know - try it. > >> by playing physmap games and mapping a page of ram at a really high >> (guest) physical address. Longterm, we need hypervisor support for >> getting a compressed view of guest physical address space, so toolstack >> side resources are proportional to the amount of RAM given to the guest, >> not to how big a guest decides to make its physmap. > Is that in your further work? It is on the list, but no idea if/how it would be done at the moment. ~Andrew