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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 15 Feb 2019, Wei Liu wrote:
> On Thu, Feb 14, 2019 at 09:03:24PM +0000, Lars Kurth wrote:
> > 
> > 
> > > On 14 Feb 2019, at 18:32, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
> > > wrote:
> > > 
> > > 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 <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.
> > 
> > @Wei: the binary size data is not that impressive. Would it be possible to 
> > do the make cloc on HVM, PV and mixed?
> > I can include this into the PR for 4.12. Sorry for slightly hi-jacking the 
> > thread.
> 
> Not sure how Stefano got the 157k number. Here are some results from
> staging.

See my attached .config

Attachment: my-config
Description: Text document

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