Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

[Jan Beulich]

>>> On 15.11.16 at 12:07, <JGross@xxxxxxxx> wrote:
> On 15/11/16 11:44, Jan Beulich wrote:
>>>>> On 15.11.16 at 10:55, <JGross@xxxxxxxx> wrote:
>>> On 15/11/16 10:45, Jan Beulich wrote:
>>>>>>> On 15.11.16 at 09:42, <JGross@xxxxxxxx> wrote:
>>>>> For a fully dynamical solution we'd need a way to get a partial
>>>>> E820 map from the hypervisor (e.g. first 128 entries) in order to
>>>>> be able to setup at least some memory and later get the rest of
>>>>> the memory map using some dynamically allocated memory.
>>>>
>>>> And we could of course also make the hypercall allow for that (e.g.
>>>> by defining the semantics of a specific error code, so far not used
>>>> by it, to avoid mis-interpretation of output on older hypervisors),
>>>> or introduce a new clone of the existing one(s).
>>>
>>> I'd go with the new error code. What about E2BIG or ENOSPC?
>> 
>> Either seems fine.
>> 
>>> I think the hypervisor should fill in the number of entries required
>>> in this case.
>> 
>> And you'd then mean the caller to imply that the passed in (and now
>> overwritten) count to describe how many entries got filled? That's
>> not that nice an interface. I'd rather return the number of entries
>> filled, and require the sizing variant (NULL handle) to be used to
>> obtain the number of entries. After all if a caller _wants_ to handle
>> a partial map, it doesn't really care how many further entries there
>> are.
> 
> I just wanted to avoid two interface changes.

Just make one at a time.

Jan