From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Umlts-0007Kq-QD for qemu-devel@nongnu.org; Wed, 12 Jun 2013 10:19:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Umltp-0008O1-CI for qemu-devel@nongnu.org; Wed, 12 Jun 2013 10:19:48 -0400 Received: from nat28.tlf.novell.com ([130.57.49.28]:59160) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Umltp-0008Nl-3I for qemu-devel@nongnu.org; Wed, 12 Jun 2013 10:19:45 -0400 Message-Id: <51B89F9D02000078000DD9F4@nat28.tlf.novell.com> Date: Wed, 12 Jun 2013 15:19:41 +0100 From: "Jan Beulich" 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> In-Reply-To: <51B87F8C.6050303@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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: Paolo Bonzini Cc: Tim Deegan , Yongjie Ren , yanqiangjun@huawei.com, Keir Fraser , Ian Campbell , hanweidong@huawei.com, George Dunlap , Xudong Hao , Stefano Stabellini , luonengjun@huawei.com, qemu-devel@nongnu.org, wangzhenguo@huawei.com, xiaowei.yang@huawei.com, arei.gonglei@huawei.com, YongweiX Xu , SongtaoX Liu , "xen-devel@lists.xensource.com" >>> On 12.06.13 at 16:02, Paolo Bonzini wrote: > Il 12/06/2013 09:49, Jan Beulich ha scritto: >>> #3 should be possible or even the default (would need to check), but = #4 >>> is probably a bit harder to do. Perhaps you can use a magic I/O port >>> for the xen platform PV driver, but if you can simply use two PCI >>> windows it would be much simpler because that's the same that TCG and >>> KVM already do. The code is all there for you to lift in SeaBIOS. >>=20 >> What is the connection here to the platform PV driver? >=20 > It's just a hook you already have for Xen-specific stuff in QEMU. Oh, sorry, I'm generally taking this term to refer to a Linux component. >>> Only Windows XP and older had problems with that because they didn't >>> like something in the ASL; but the 64-bit window is placed at the end = of >>> RAM, so in principle any PAE-enabled OS can use it. >>=20 >> At the end of _RAM_??? >=20 > Why the question marks? :) Ah, so mean right after RAM. "At the end of RAM" reads like overlapping (and discarding) the tail of it. > 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. Jan From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M Date: Wed, 12 Jun 2013 15:19:41 +0100 Message-ID: <51B89F9D02000078000DD9F4@nat28.tlf.novell.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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <51B87F8C.6050303@redhat.com> Content-Disposition: inline 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: Paolo Bonzini Cc: Tim Deegan , Yongjie Ren , yanqiangjun@huawei.com, Keir Fraser , Ian Campbell , hanweidong@huawei.com, George Dunlap , Xudong Hao , Stefano Stabellini , luonengjun@huawei.com, qemu-devel@nongnu.org, wangzhenguo@huawei.com, xiaowei.yang@huawei.com, arei.gonglei@huawei.com, YongweiX Xu , SongtaoX Liu , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> On 12.06.13 at 16:02, Paolo Bonzini wrote: > Il 12/06/2013 09:49, Jan Beulich ha scritto: >>> #3 should be possible or even the default (would need to check), but = #4 >>> is probably a bit harder to do. Perhaps you can use a magic I/O port >>> for the xen platform PV driver, but if you can simply use two PCI >>> windows it would be much simpler because that's the same that TCG and >>> KVM already do. The code is all there for you to lift in SeaBIOS. >>=20 >> What is the connection here to the platform PV driver? >=20 > It's just a hook you already have for Xen-specific stuff in QEMU. Oh, sorry, I'm generally taking this term to refer to a Linux component. >>> Only Windows XP and older had problems with that because they didn't >>> like something in the ASL; but the 64-bit window is placed at the end = of >>> RAM, so in principle any PAE-enabled OS can use it. >>=20 >> At the end of _RAM_??? >=20 > Why the question marks? :) Ah, so mean right after RAM. "At the end of RAM" reads like overlapping (and discarding) the tail of it. > 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. Jan