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

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> 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.

 -George

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