From: George Dunlap <george.dunlap@eu.citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@citrix.com>,
Hanweidong <hanweidong@huawei.com>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
xen-devel@lists.xen.org
Subject: Re: [PATCH] libxl, hvmloader: Don't relocate memory for MMIO hole
Date: Mon, 17 Jun 2013 17:48:35 +0100 [thread overview]
Message-ID: <51BF3DE3.2060709@eu.citrix.com> (raw)
In-Reply-To: <1371487427-13025-1-git-send-email-george.dunlap@eu.citrix.com>
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 <george.dunlap@eu.citrix.com>
> CC: Ian Campbell <ian.campbell@citrix.com>
> CC: Ian Jackson <ian.jackson@citrix.com>
> CC: Stefano Stabellini <stefano.stabellini@citrix.com>
> CC: Hanweidong <hanweidong@huawei.com>
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
next prev parent reply other threads:[~2013-06-17 16:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-17 16:43 [PATCH] libxl, hvmloader: Don't relocate memory for MMIO hole George Dunlap
2013-06-17 16:48 ` George Dunlap [this message]
2013-06-18 12:18 ` Hanweidong
2013-06-18 12:20 ` George Dunlap
2013-06-18 12:46 ` Hanweidong
2013-06-18 12:51 ` George Dunlap
2013-06-18 12:44 ` George Dunlap
2013-06-18 12:54 ` Hanweidong
2013-06-17 17:02 ` George Dunlap
2013-06-17 17:09 ` Wei Liu
2013-06-17 17:15 ` Ian Jackson
2013-06-18 9:50 ` George Dunlap
2013-06-18 9:57 ` George Dunlap
2013-06-18 10:53 ` Ian Jackson
2013-06-18 11:43 ` George Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51BF3DE3.2060709@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=hanweidong@huawei.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@citrix.com \
--cc=stefano.stabellini@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.