> On 14 Feb 2019, at 18:32, Stefano Stabellini <sstabell...@kernel.org> wrote:
>
> On Thu, 14 Feb 2019, Jan Beulich wrote:
>>>>> On 13.02.19 at 20:11, <sstabell...@kernel.org> wrote:
>>> On Wed, 13 Feb 2019, Wei Liu wrote:
>>>> On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
>>>>> Greetings,
>>>>>
>>>>> On the 11/14/18 Xen x86 community call a discussion was initiated about
>>>>> using Kconfig to build minimized versions of Xen for security, safety
>>>>> and other certification requirements. After some offline discussions
>>>>> with Xen contributors I realized that a variety of efforts each with
>>>>> their own respective goals are underway,
>>>>>
>>>>> - nested virtualization
>>>>> - mixed criticality architectures
>>>>> - reducing trusted componentary
>>>>> - combining hardware protection of virtualization with performance and
>>>>> ease-of-use of containers
>>>>>
>>>>> These efforts use hypervisors in different roles, all which Xen is
>>>>> capable of meeting. Today Xen's utility comes at the expense of carrying
>>>>> features necessary for one role to be present in another role where it
>>>>> is not required, e.g. PV interfaces that may not be essential in an ARM
>>>>> mixed criticality deployment.
>>>>>
>>>>> The initial focus will be to explore and document the range of possible
>>>>> use cases that are of interest to the Xen community. This will be the
>>>>> input to a design document that is crafted in conjunction with the Xen
>>>>> maintainers, to identify possible approaches to extend the existing
>>>>> Kconfig infrastructure to produce tailored instances of Xen.
>>>>>
>>>>> If you are interested in participating in this effort, please reply to
>>>>> this thread to outline possible use cases, design constraints and other
>>>>> considerations for improving Xen's Kconfig infrastructure to support
>>>>> tailoring for specific use cases.
>>>>>
>>>>
>>>> My impression from the community call is that you want to provide
>>>> smallish configurations for different use cases.
>>>>
>>>> The Kconfig infrastructure is already able to do what you want as far as
>>>> I can tell. You can easily feed it a base config file -- see files
>>>> under automation/configs/x86/. What sort of extension is needed in your
>>>> opinion?
>>>>
>>>> As use case goes, it would be a good start if you just submit something
>>>> you care about.
>>>
>>> I mentioned on the call that a good first start could be a kconfig that
>>> allows to build an hypervisor binary with only support for PVH and only
>>> support for recent Intel machines, with the goal of minimizing the code
>>> base to less than 100K LOC.
>>
>> "With only support for PVH" (which really means HVM) we already have.
>> "With only support for recent Intel machines" would require adding new
>> Kconfig options first, to control Intel, AMD, etc separately, and to then
>> further somehow separate "old" from "new" (which may turn out not
>> very easy to do without a lot of #ifdef-ary or other code churn). I'm
>> not aware of something like this existing on Linux either - all I'm aware
>> of there is a means to control what -m<arch> option might be passed
>> to the compiler, but without disabling any source code from getting
>> compiled.
>
> I was thinking along the lines of having options to disable drivers for
> older timers and older interrupt controllers that are not needed on
> recent machines.
>
>
>> And then "with only support for recent Intel machines" could also imply
>> HAP-only; disabling shadow code (which also is already possible) will
>> alone save almost 10k LOC (counting .c files only).
>
> I have just run `make cloc' on x86 with the smallest possible
> configuration (HVM only):
>
>
> http://cloc.sourceforge.net <http://cloc.sourceforge.net/> v 1.60 T=0.87 s
> (370.3 files/s, 255808.4 lines/s)
> -------------------------------------------------------------------------------
> Language files blank comment
> code
> -------------------------------------------------------------------------------
> C 309 33238 29432
> 157001
> Assembly 14 466 531
> 2435
> -------------------------------------------------------------------------------
> SUM: 323 33704 29963
> 159436
> -------------------------------------------------------------------------------
>
> This is great! The last time I did the count it was above 220K LOC. We
> should make more noise about this -- it is a major.
@Wei: the binary size data is not that impressive. Would it be possible to do
the make cloc on HVM, PV and mixed?
I can include this into the PR for 4.12. Sorry for slightly hi-jacking the
thread.
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
