From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gordan Bobic <gordan@bobich.net>
Subject: Re:
 =?utf-8?q?Bug=3A_Limitation_of_=3C=3D2GB_RAM_in_domU_?=
 =?utf-8?q?persists_with_4=2E3=2E0?=
Date: Fri, 26 Jul 2013 10:28:12 +0100
Message-ID: <ce1e6ddedea6335d73b178f586e2be38@mail.shatteredsilicon.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>
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: <CAN1tX1idrgoGtrxhN9VnqjP7Ag5q_iHPjD7d=R3SM=_cCzj4=A@mail.gmail.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: Andrew Bobulsky <rulerof@gmail.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

 On Thu, 25 Jul 2013 21:15:10 -0400, 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

 Now that is intereting - if this makes the memory holes the same 
 between
 the guest and the host, does it also implicitly vBAR=pBAR?

 Gordan