linux-kernel - Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 15 Nov 2016 04:12:38 -0700
From:   "Jan Beulich" <JBeulich@...e.com>
To:     "Juergen Gross" <JGross@...e.com>
Cc:     "David Vrabel" <david.vrabel@...rix.com>, <x86@...nel.org>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        <xen-devel@...ts.xenproject.org>, "Ingo Molnar" <mingo@...hat.com>,
        "Alex Thorlton" <athorlton@....com>, "Russ Anderson" <rja@....com>,
        <linux-kernel@...r.kernel.org>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX
 possible entries

>>> On 15.11.16 at 12:07, <JGross@...e.com> wrote:
> On 15/11/16 11:44, Jan Beulich wrote:
>>>>> On 15.11.16 at 10:55, <JGross@...e.com> wrote:
>>> On 15/11/16 10:45, Jan Beulich wrote:
>>>>>>> On 15.11.16 at 09:42, <JGross@...e.com> 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