From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M Date: Wed, 12 Jun 2013 16:25:12 +0100 Message-ID: <51B892D8.5040401@eu.citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51B89F9D02000078000DD9F4@nat28.tlf.novell.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: Jan Beulich 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, YongweiX Xu , Paolo Bonzini , SongtaoX Liu , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 12/06/13 15:19, Jan Beulich wrote: >>>> 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. >>> What is the connection here to the platform PV driver? >> 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. >>> At the end of _RAM_??? >> 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. 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. -George