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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Oct 29, 2013 at 12:29:02PM +0000, George Dunlap wrote:
> 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>

Thanks, could you also ack V3 patch (the latest one) -- this is the first
version.

Wei.

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