[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |