[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Bug: Limitation of <=2GB RAM in domU persists with 4.3.0



On 31/07/13 18:53, George Dunlap wrote:
> On Fri, Jul 26, 2013 at 2:11 PM, Gordan Bobic <gordan@xxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.