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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.