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

Re: [Xen-devel] [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048



On Fri, Nov 01, 2013 at 04:02:17PM +0000, Ian Campbell wrote:
> On Tue, 2013-10-29 at 11:39 +0000, Wei Liu wrote:
> > When using OVMF we need to have 1MiB of memory in place for firmware.
> > Without this change we have:
> > 
> > (XEN) HVM128: Loading OVMF ...
> > (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024
> > (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 
> > memflags=0 (0 of 1)
> > 
> > This is not a fatal error as hvmloader will instead use low memory to
> > load OVMF, but it's better to eliminate such error.
> > 
> > Changing this constant doesn't necessary increase the total amount of
> > memory a guest uses because it's just a limit.
> 
> It will allow a guest to try and use up to 1MB more though, and it
> allows this for PV guests as well as HVM guests not using OVMF.
> 
> There's only a small number of place which use this constant, can we
> refactor them into a helper function, which can then be expanded to
> include a per-BIOS overhead in addition to this one? The BIOS selection
> is stored in xenstore, so that work even for calls which don't have the
> domain configuration to hand.
> 
> (does anyone remember what the existing 1MB is actually for?)
> 

Happened to come across this when I was looking at other problem.

http://lists.xen.org/archives/html/xen-devel/2009-12/msg00401.html

It looks like that constant was never intended to use in the way it is
now. Hah.

Wei.

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