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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M Date: Wed, 12 Jun 2013 16:13:23 -0400 Message-ID: <51B8D663.70503@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51B892D8.5040401@eu.citrix.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org 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" List-Id: xen-devel@lists.xenproject.org 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