From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmrQU-0005Yb-CW for qemu-devel@nongnu.org; Wed, 12 Jun 2013 16:13:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UmrQS-0001Cs-BP for qemu-devel@nongnu.org; Wed, 12 Jun 2013 16:13:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UmrQR-0001Ce-Vz for qemu-devel@nongnu.org; Wed, 12 Jun 2013 16:13:48 -0400 Message-ID: <51B8D663.70503@redhat.com> Date: Wed, 12 Jun 2013 16:13:23 -0400 From: Paolo Bonzini MIME-Version: 1.0 References: <51B1FF50.90406@eu.citrix.com> <403610A45A2B5242BD291EDAE8B37D3010E56731@SHSMSX102.ccr.corp.intel.com> <51B83E7A02000078000DD6E9@nat28.tlf.novell.com> <51B847E3.5010604@eu.citrix.com> <51B87636.5010404@redhat.com> <51B8988602000078000DD98D@nat28.tlf.novell.com> <51B87F8C.6050303@redhat.com> <51B89F9D02000078000DD9F4@nat28.tlf.novell.com> <51B892D8.5040401@eu.citrix.com> In-Reply-To: <51B892D8.5040401@eu.citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: George Dunlap Cc: Tim Deegan , Yongjie Ren , yanqiangjun@huawei.com, Keir Fraser , Ian Campbell , hanweidong@huawei.com, Xudong Hao , Stefano Stabellini , luonengjun@huawei.com, qemu-devel@nongnu.org, wangzhenguo@huawei.com, xiaowei.yang@huawei.com, arei.gonglei@huawei.com, Jan Beulich , YongweiX Xu , SongtaoX Liu , "xen-devel@lists.xensource.com" Il 12/06/2013 11:25, George Dunlap ha scritto: >>> If you have 4GB of RAM it will end at 0x140000000 (or something like >>> that) and that's where the 64-bit window starts. Of course if you have >>> no RAM above the PCI hole, the 64-bit window will start at 0x100000000. >> So there's no provision whatsoever for extending the amount of RAM >> a guest may see? This is why I'd see any such allocation strategy to >> start at the end of physical address space, moving downwards. That'd work too, I guess. > Is there a mechanism to do memory hot-plug in qemu at the moment? If > not, then there's no reason to put it anywhere else. Not yet, but then memory could also be discontiguous as long as you describe it correctly in the tables. Paolo