Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Feb 15, 2019, at 5:36 PM, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
> wrote:
> 
> On Fri, 15 Feb 2019, George Dunlap wrote:
>>> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
>>> 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.
>> 
>> I think one thing that might be helpful is a sort of “feature document” for 
>> each defconfig we’re looking at creating.  This would include:
>> 
>> * What the “target use case” for each defconfig would be
>> * The end goal in terms of functionality / LoC / whatever
>> * The current state, work items yet to do
>> * What potential variations there are (i.e., how to enable shadow if you 
>> want, or switch from Intel-only to AMD-only)
>> 
>> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying 
>> where we want to go, and moving things from “to do” to “done” as they get 
>> implemented.  That would make it easier to have in-progress things in the 
>> tree, make it easier for people to collaborate / enhance defconfigs, and 
>> also be a starting point for talking about testing and support status.
> 
> +1
> 
> Just to set the expectations right on this thread: I am just trying to
> provide feedback from the field, things I know are important to the Xen
> on x86 embedded user community. I am not going to take this on as a work
> item.  But somebody else might? Daniel Smith, I am looking at you :-)

I tried to make this clear on the call, but just in case, let me try to repeat 
/ expand on what I said:

When creating a brand-new thing like this, the best thing is for each 
person/org to make exactly the thing that they want.  Daniel shouldn’t be 
trying to make a defconfig for embedded x86 hypervisors unless that’s 
specifically what he wants to use: he should be making a defconfig for his 
specific use case.

When someone else comes along and wants the second instance of whatever this 
thing is, we can then refactor our system based on two people’s real actual 
requirements.

The only time to try to sit and plan a General Purpose Thing are:
1. When you already have loads of instances, so you have a clear idea what a 
General Purpose Thing of this type looks like
2. When you need to worry about backwards compatibility.

I don’t think #1 or #2 are true in this case; so the most efficient thing will 
be for Daniel to make exactly the thing that he himself wants, spending very 
little time on attempting to make it a General Purpose Thing that someone else 
might want.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel