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] [thread-next>] [day] [month] [year] [list]

Message-Id: <582AF51F020000780011ECB4@prv-mh.provo.novell.com>
Date:   Tue, 15 Nov 2016 03:44:31 -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 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.

Jan