From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: xc: error: xc_machphys_mfn_list: 83 != 129 when suspending 32GB PV DomU Date: Fri, 11 Mar 2011 19:21:35 +0000 Message-ID: References: <1299869540.17229.72.camel@qabil.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1299869540.17229.72.camel@qabil.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Gianni Tedesco , Xen Devel Cc: Tim Deegan , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 11/03/2011 18:52, "Gianni Tedesco" wrote: > Further debugging reveals the variables are set as such: > (XEN) compat_machine_to_phys_mapping = 18446606377058041856 > (XEN) max_page = 67272704 > (XEN) MACH2PHYS_COMPAT_NR_ENTRIES(current->domain) = 43515904 > (XEN) RDWR_COMPAT_MPT_VIRT_START = 18446606377058041856 > (XEN) RDWR_COMPAT_MPT_VIRT_END = 18446606378131783680 > (XEN) limit = 18446606377232105472, (1 << L2_PAGETABLE_SHIFT) = 2097152 > > Could it be that the compat mach-to-phys conversion table size of 1GB is > too small? It is insufficient to cover all of the system's memory. The reason for the limit is that a 1GB M2P table is all that is reasonable to map into a 32-bit domain's address space while still leaving space for the guest's own mappings. We could make the compat m2p bigger solely for mapping by dom0 when doing save/restore? However, you'd likely still soon hit the mmap limit for the save/restore process in dom0. It might extend the lifetime of your 32-bit dom0 for a bit longer however. Long enough for the lightweight HVM container for PV guests work to get checked in and make our PV 64-bit guest performance better. -- Keir > Or that there exists some other arbitrary limit on the size > of domains that can be suspended [when using a 32bit dom0] ?