From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Bug: Limitation of <=2GB RAM in domU persists with
 4.3.0
Date: Wed, 31 Jul 2013 18:56:02 +0100
Message-ID: <51F94FB2.9060803@citrix.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAFLBxZai8V21658+PC2UfW4HxkviPBbvBhLbp+u8+mE+_Wg2WA@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: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Andrew Bobulsky <rulerof@gmail.com>, Gordan Bobic <gordan@bobich.net>, Ian Campbell <ian.campbell@citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

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...
>
>  -George

I believe it did - the patch does not exist in our patch queue any more.

~Andrew