From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gordan Bobic <gordan@bobich.net>
Subject: Re: Bug: Limitation of <=2GB RAM in domU persists with
 4.3.0
Date: Sun, 28 Jul 2013 22:24:05 +0100
Message-ID: <51F58BF5.6020307@bobich.net>
References: <51EF04D8.1090600@bobich.net>
	<20130724140813.GH2518@phenom.dumpdata.com>
	<2aa84a31b7b17c2ea6d8483a281ad3f5@mail.shatteredsilicon.net>
	<20130724160639.GB5804@phenom.dumpdata.com>
	<8426aecf79e7f55c21bbe259014591a2@mail.shatteredsilicon.net>
	<20130724163102.GA6308@phenom.dumpdata.com>
	<51F051F1.5050806@bobich.net>
	<CAFLBxZZjvWchAr3SkcWOScgNxz5onZW8DX8H+hm_UzC-sFDJjw@mail.gmail.com>
	<51F19D11.1090200@bobich.net> <51F1A54D.6070906@bobich.net>
	<1374798084.10269.2.camel@hastur.hellion.org.uk>
	<CAN1tX1idrgoGtrxhN9VnqjP7Ag5q_iHPjD7d=R3SM=_cCzj4=A@mail.gmail.com>
	<81f6318c-2a27-41ec-afc0-c6b642554bad@email.android.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <81f6318c-2a27-41ec-afc0-c6b642554bad@email.android.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Andrew Bobulsky <rulerof@gmail.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Ian Campbell <ian.campbell@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 07/28/2013 11:26 AM, Konrad Rzeszutek Wilk wrote:
> Andrew Bobulsky <rulerof@gmail.com> wrote:
>> On Thu, Jul 25, 2013 at 8:21 PM, Ian Campbell <ian.campbell@citrix.com>
>> wrote:
>>> On Thu, 2013-07-25 at 23:23 +0100, Gordan Bobic wrote:
>>>> Now, if I am understanding the basic nature of the problem
>> correctly,
>>>> this _could_ be worked around by ensuring that vBAR = pBAR since in
>> that
>>>> case there is no room for the mis-mapped memory overwrites to occur.
>> Is
>>>> that correct?
>>>
>>> AIUI (which is not very well...) it's not so much vBAR=pBAR but
>> making
>>> the guest e820 (memory map) have the same MMIO holes as the host so
>> that
>>> there can't be any clash between v- or p-BAR and RAM in the guest.
>>>
>>>> I guess I could test this easily enough by applying the vBAR = pBAR
>> hack.
>>>
>>> Does the e820_host=1 option help? That might be PV only though, I
>> can't
>>> remember...
>>
>> Alas, yes.  The man pages list it under "PV Guest Specific Options":
>> http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
>>
>> You got my hopes up! ;)
>>
>> Carry on!  I'll be sitting here metaphorically munching popcorn with
>> anticipation :P
>
> We could implement that for HVM guests too. But I am not sure about
> the consequences of this for migration (say you unplug the device
> beforehand and then migrate to another host which has a different
> E820). That part requires a bit of pondering.

Just out of interest, what happens in case where the PV guests get 
migrated with e820_host=1 set?

Gordan