From mboxrd@z Thu Jan 1 00:00:00 1970 From: "SourceForge.net" Subject: [ kvm-Bugs-1971512 ] failure to migrate guests with more than 4GB of RAM Date: Mon, 26 May 2008 09:48:12 -0700 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To: noreply@sourceforge.net Return-path: Received: from lists.sourceforge.net ([66.35.250.206]:58977 "EHLO mail.sourceforge.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750984AbYEZQsN (ORCPT ); Mon, 26 May 2008 12:48:13 -0400 Sender: kvm-owner@vger.kernel.org List-ID: Bugs item #1971512, was opened at 2008-05-24 17:45 Message generated for change (Comment added) made by aliguori You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1971512&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Marcelo Tosatti (mtosatti) Assigned to: Anthony Liguori (aliguori) Summary: failure to migrate guests with more than 4GB of RAM Initial Comment: The migration code assumes linear "phys_ram_base": [root@localhost kvm-userspace.tip]# qemu/x86_64-softmmu/qemu-system-x86_64 -hda /root/images/marcelo5-io-test.img -m 4097 -net nic,model=rtl8139 -net tap,script=/root/iptables/ifup -incoming tcp://0:4444/ audit_log_user_command(): Connection refused audit_log_user_command(): Connection refused migration: memory size mismatch: recv 22032384 mine 4316999680 migrate_incoming_fd failed (rc=232) ---------------------------------------------------------------------- >Comment By: Anthony Liguori (aliguori) Date: 2008-05-26 12:48 Message: Logged In: YES user_id=120449 Originator: NO The issue isn't actually the use of phys_ram_base. In the case of migration, we don't care about the layout of physical memory. We just want to look at memory from phys_ram_base .. ram_size. The problem is that we encode physical addresses in the migration protocol as 32-bit values. We'll need to figure out a way to switch to encoding PFNs while maintaining backwards compatibility with the current code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1971512&group_id=180599