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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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 :-)

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