This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] xc: error: xc_machphys_mfn_list: 83 != 129 when suspending 3

To: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] xc: error: xc_machphys_mfn_list: 83 != 129 when suspending 32GB PV DomU
From: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Date: Fri, 11 Mar 2011 18:52:20 +0000
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxx>
Delivery-date: Fri, 11 Mar 2011 10:53:12 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

I have a 256GB host and run a 32GB 64-bit PV domain (SLES 11) on it.
When I try and suspend the domain, xc barfs with:

 xc: error: xc_machphys_mfn_list: 83 != 129: Internal error
 xc: error: xc_get_m2p_mfns (0 = Success): Internal error
 xc: error: Failed to map live M2P table (0 = Success): Internal error

At first, since dom0 is 32 bit, I suspected the compat layer. However
the hypercall in xen/arch/x86/x86_64/compat/mm.c compat_arch_memory_op()
seems to agree with the numbers:

 (XEN) compat_arch_memory_op returned 0 (nr_extents = 83, max_extents = 129)

>From this I conclude that everything is working OK at the hypercall
layer. However, looking at the code in compat_arch_memory_op() it
appears that the code is failing due to some arcane limits of the compat
subsystem. The following code to establish the variable 'limit' is
causing the loop to exit early:

    limit = (unsigned long)(compat_machine_to_phys_mapping +
        min_t(unsigned long, max_page,
    if ( limit > RDWR_COMPAT_MPT_VIRT_END )
         limit = RDWR_COMPAT_MPT_VIRT_END;
    for ( i = 0, v = RDWR_COMPAT_MPT_VIRT_START, last_mfn = 0;
         (i != xmml.max_extents) && (v < limit);
          i++, v += 1 << L2_PAGETABLE_SHIFT )
        /* do stuff */
    xmml.nr_extents = i;

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? Or that there exists some other arbitrary limit on the size
of domains that can be suspended [when using a 32bit dom0] ?


Xen-devel mailing list