From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] libxl, hvmloader: Don't relocate memory for MMIO hole Date: Mon, 17 Jun 2013 17:48:35 +0100 Message-ID: <51BF3DE3.2060709@eu.citrix.com> References: <1371487427-13025-1-git-send-email-george.dunlap@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1371487427-13025-1-git-send-email-george.dunlap@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Ian Jackson , Hanweidong , Stefano Stabellini , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 17/06/13 17:43, George Dunlap wrote: > At the moment, qemu-xen can't handle memory being relocated by > hvmloader. This may happen if a device with a large enough memory > region is passed through to the guest. At the moment, if this > happens, then at some point in the future qemu will crash and the > domain will hang. (qemu-traditional is fine.) > > It's too late in the release to do a proper fix, so we try to do > damage control. > > hvmloader already has mechanisms to relocate memory to 64-bit space > if it can't make a big enough MMIO hole. By default this is 2GiB; if > we just refuse to make the hole bigger if it will overlap with guest > memory, then this codepath will be taken by default. > > Signed-off-by: George Dunlap > CC: Ian Campbell > CC: Ian Jackson > CC: Stefano Stabellini > CC: Hanweidong Unfortunatley, I don't have an easy way to test this, as all of the devices on my system are far smaller than 256MiB. Weidong, could you give this patch a try and see if it works for you? -George