[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.