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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 14 Feb 2019, Jan Beulich wrote:
> >>> On 13.02.19 at 20:11, <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.
> 
> "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 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.


Do you have any other suggestions about things that could be removed to
reach down to 100K LOC, in addition to what you have already written
above (Intel/AMD, shadow)?

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