[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 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@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...


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


_______________________________________________
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®.