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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 10/29/2013 12:24 PM, Wei Liu wrote:
> 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.
Hmm, I guess the firmware stays in memory even after the guest boots, 
doesn't it.
In any case, at the moment if that's how the firmware is treated, then 
it's probably best to just go along with it.  If we want to change that, 
we can consider doing that as a separate thing for the next release.
The name of this constant could use some change too -- it should be 
"LIBXL_MEMORY_SLACK" or something like that, perhaps with a comment to 
indicate what the slack is used for.  But that's not necessary for this 
patch series either, I don't think.
Acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>

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