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

Re: [Xen-devel] [PATCH 1/2] xen/x86: return partial memory map in case of not enough space



>>> On 06.12.16 at 08:43, <JGross@xxxxxxxx> wrote:
> On 05/12/16 18:17, Jan Beulich wrote:
>>>>> On 05.12.16 at 17:34, <JGross@xxxxxxxx> wrote:
>>> For XENMEM_machine_memory_map the hypervisor returns EINVAL if the
>>> caller's buffer can't hold all entries.
>>>
>>> This is a problem as the caller has normally a static buffer defined
>>> and when he is doing the call no dynamic memory allocation is
>>> possible as nothing is yet known about the system's memory layout.
>>>
>>> Instead of just fail deliver as many memory map entries as possible
>>> and return with E2BIG indicating the result was incomplete. Then the
>>> caller will be capable to use at least some memory reported to exist
>>> to allocate a larger buffer for the complete memory map.
>> 
>> This makes no sense, as what we're talking about here is the
>> machine memory map, and the calling Dom0 kernel can't allocate
>> from that pool directly. Instead it would need its own memory
>> map to know where to place such a larger buffer, and this map
>> is usually just one or two entries large.
> 
> This is true. In practice, however, things are a little bit more
> complicated:
> 
> Linux being started as dom0 tries to rearrange memory layout to match
> the one of the physical machine. It will only add memory to its
> allocator which is known to either not need to be moved or which has
> already been moved. And this decision is based on the machine memory
> map.

Right, I did recall this oddity only after having sent the initial reply
(I'm still much more into how the non-pvops kernel works, and there's
no such dependency there).

> I admit it is a Linux kernel private decision how to handle the boot and
> adding of memory to its allocator. OTOH the "all or nothing" approach of
> the hypervisor regarding delivery of the machine memory map is a little
> bit strange, especially as the BIOS is returning the E820 map one entry
> after the other.
> 
>> For that reason I'm not convinced we need or want this change.
> 
> It would certainly make it easier for the Linux kernel.

I'd like us to at least consider alternatives:

1) Have a new sub-op behaving BIOS like (one entry at a time).

2) Make the full map available inside the initial mapping, pointed to
by a new entry in the start info structure.

3) Have pvops Linux make use of the extra space available at the
end of the initial mapping. The minimum of 512k there should be
more than enough.

4) Others I can't think of right now.

Jan


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

 


Rackspace

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