[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: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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |