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: Wed, 31 Jul 2013 20:36:03 +0100
Message-ID: <51F96723.4040601@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>
	<ce1e6ddedea6335d73b178f586e2be38@mail.shatteredsilicon.net>
	<4e207d63809542544ebe45866e746e91@mail.shatteredsilicon.net>
	<CAFLBxZai8V21658+PC2UfW4HxkviPBbvBhLbp+u8+mE+_Wg2WA@mail.gmail.com>
	<51F94FB2.9060803@citrix.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: <51F94FB2.9060803@citrix.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 Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Andrew Bobulsky <rulerof@gmail.com>, Ian Campbell <ian.campbell@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 07/31/2013 06:56 PM, Andrew Cooper wrote:
> On 31/07/13 18:53, George Dunlap wrote:
>> On Fri, Jul 26, 2013 at 2:11 PM, Gordan Bobic <gordan@bobich.net> wrote:
>>>> Now that is intereting - if this makes the memory holes the same between
>>>> the guest and the host, does it also implicitly vBAR=pBAR?
>>>
>>> Another thing that occurred to me might be useful to check - it is
>>> pretty easy to modify the BAR size on Nvidia cards. The defaults are
>>> 64MB and 128MB for the two BARs. They can be made much, much larger,
>>> and there is often advantage to enlarging them to at least be equal to
>>> VRAM size. Soooooo... If I boost the BAR from 128MB to 2GB, being a
>>> 64-bit BAR, it might make the BIOS do the sane thing and map it above
>>> 4GB. With the other BAR also suitably enlarged and it being done on
>>> the second GPU as well, there is no obvious option but to map them
>>> above 4GB (unless the BIOS is broken, which it may well be, in
>>> which case all bets are off).
>>>
>>> Which may just alleviate the memory issue if not completely fix
>>> the problem.
>>>
>>> Will try this and see what happens.
>> I believe XenServer has a patch that allows the toolstack (in this
>> case xapi) to set the default size of the MMIO hole.  Andrew, did that
>> ever make it upstream?
>>
>> Unfortunately, it is unlikely to work with upstream qemu until we fix
>> the memory relocation issue...
>>
>
> I believe it did - the patch does not exist in our patch queue any more.

Can anyone point me at the relevant commit / docs on this patch?

Gordan