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

[Juergen Gross <jgross@xxxxxxxx>]

On 06/12/16 09:15, Jan Beulich wrote:
>>>> 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).

No objections from me.

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

What about PVH?

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

This would mean using this area as a temporary buffer and copying the
obtained map somewhere else (either only in the size of the static
buffer or after reorganizing the memory according to the map). I guess
this would work, too.

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

My preference would be 1). In case we are choosing this approach I
don't see any need for the other patch I sent for getting the number
of entries. It can easily be replaced by a loop of the single entry
solution.


Juergen

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