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

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



On Tue, Oct 29, 2013 at 12:15:13PM +0000, Wei Liu wrote:
> On Tue, Oct 29, 2013 at 12:03:25PM +0000, George Dunlap wrote:
> > On Tue, Oct 15, 2013 at 5:40 PM, Wei Liu <wei.liu2@xxxxxxxxxx> 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.
> > 
> > Wait -- hvmloader is actually allocating memory from Xen to load
> > firmware stuff like this?
> > 
> > That seems a bit weird... shouldn't it just use the memory it already
> > has, instead of asking for more?
> > 
> 
> See hvmloader/util.c:mem_hole_populate_ram(). It's used in building ACPI
> info area and allocating ram to load OVMF firmware volume.
> 
> Are you suggesting we change the behavior of hvmloader?
> 

I think this boils down to the question whether firmware should be
considered extra overhead, like shadow ram.

Wei.

> Wei.
> 
> >  -George

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