All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Lars Kurth <lars.kurth.xen@gmail.com>
Cc: James McKenzie <james.mckenzie@bromium.com>,
	robin.randhawa@arm.com, Wei Liu <wei.liu2@citrix.com>,
	'Jan Beulich' <JBeulich@suse.com>,
	Daniel Smith <dpsmith@apertussolutions.com>,
	Doug Goldstein <cardoe@cardoe.com>,
	Christopher Clark <christopher.w.clark@gmail.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	"Daniel P.Smith" <dpsmith.dev@gmail.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	committers@xenproject.org,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Stewart Hildebrand <Stewart.Hildebrand@dornerworks.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Paul Durrant <paul.durrant@citrix.com>
Subject: Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions
Date: Fri, 15 Feb 2019 11:08:07 +0000	[thread overview]
Message-ID: <20190215110807.jtybxyfl523vwo3y@zion.uk.xensource.com> (raw)
In-Reply-To: <AB54071B-07B5-4FFC-A1A4-781C24F61D93@gmail.com>

On Thu, Feb 14, 2019 at 09:03:24PM +0000, Lars Kurth wrote:
> 
> 
> > On 14 Feb 2019, at 18:32, Stefano Stabellini <sstabellini@kernel.org> wrote:
> > 
> > On Thu, 14 Feb 2019, Jan Beulich wrote:
> >>>>> On 13.02.19 at 20:11, <sstabellini@kernel.org> 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.


* Full build

cloc --list-file=/tmp/tmp.sSYTTwC8vo
     368 text files.
     359 unique files.
       6 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.73 s (489.4 files/s, 342664.7 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                              336          35990          32543         174886
Assembly                        19            700            918           3534
-------------------------------------------------------------------------------
SUM:                           355          36690          33461         178420
-------------------------------------------------------------------------------
rm /tmp/tmp.sSYTTwC8vo

* HVM only with shadow

cloc --list-file=/tmp/tmp.dr9H29oAjZ
     350 text files.
     341 unique files.
       6 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.70 s (481.2 files/s, 345675.6 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                              319          35114          31729         170552
Assembly                        18            665            857           3188
-------------------------------------------------------------------------------
SUM:                           337          35779          32586         173740
-------------------------------------------------------------------------------
rm /tmp/tmp.dr9H29oAjZ


* PV only with shadow

cloc --list-file=/tmp/tmp.iFlA6cYriw
     307 text files.
     300 unique files.
       5 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.59 s (502.7 files/s, 338427.3 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                              280          28300          26343         140419
Assembly                        17            658            848           3386
-------------------------------------------------------------------------------
SUM:                           297          28958          27191         143805
-------------------------------------------------------------------------------
rm /tmp/tmp.iFlA6cYriw


* HVM only without shadow

cloc --list-file=/tmp/tmp.xX9DEaEw14
     346 text files.
     339 unique files.
       5 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.69 s (487.1 files/s, 344973.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                              318          34576          30963         167736
Assembly                        18            665            857           3188
-------------------------------------------------------------------------------
SUM:                           336          35241          31820         170924
-------------------------------------------------------------------------------
rm /tmp/tmp.xX9DEaEw14


* PV only without shadow

cloc --list-file=/tmp/tmp.w2YYkxG90d
     302 text files.
     299 unique files.
       3 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.62 s (484.2 files/s, 319189.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                              280          27835          25697         137998
Assembly                        18            660            848           3395
-------------------------------------------------------------------------------
SUM:                           298          28495          26545         141393
-------------------------------------------------------------------------------
rm /tmp/tmp.w2YYkxG90d

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

  reply	other threads:[~2019-02-15 11:08 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-13  2:34 Enhancing Xen's Kconfig infrastructure to support tailored solutions Daniel P. Smith
2019-02-13 11:13 ` Jan Beulich
2019-02-13 18:25 ` Wei Liu
2019-02-13 19:11   ` Stefano Stabellini
2019-02-14  9:53     ` Jan Beulich
2019-02-14 18:32       ` Stefano Stabellini
2019-02-14 18:57         ` Andrew Cooper
2019-02-15  8:43           ` Jan Beulich
2019-02-14 21:03         ` Lars Kurth
2019-02-15 11:08           ` Wei Liu [this message]
2019-02-15 19:08             ` Stefano Stabellini
2019-02-18 11:12               ` Wei Liu
2019-02-18 11:17                 ` Lars Kurth
2019-02-18 11:23                   ` Wei Liu
2019-02-18 11:30                     ` George Dunlap
2019-02-18 11:53                       ` Lars Kurth
2019-02-18 11:57                         ` Wei Liu
2019-02-18 12:00                           ` Lars Kurth
2019-02-18 12:01                           ` Andrew Cooper
2019-02-18 12:11                             ` Lars Kurth
2019-02-18 12:11                             ` George Dunlap
2019-02-18 12:16                               ` George Dunlap
2019-02-18 12:54                                 ` Lars Kurth
2019-02-19 19:13                                   ` Stefano Stabellini
2019-02-19 21:05                                     ` P S
2019-02-15  8:52         ` Jan Beulich
2019-02-15 17:27           ` Stefano Stabellini
2019-02-15 10:58         ` Wei Liu
2019-02-14 18:52       ` Andrew Cooper
2019-02-15  9:35     ` George Dunlap
2019-02-15 11:10       ` Lars Kurth
2019-02-15 17:36       ` Stefano Stabellini
2019-02-15 17:55         ` George Dunlap
2019-02-15 18:27           ` Stefano Stabellini
2019-02-24 14:52       ` Daniel P. Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190215110807.jtybxyfl523vwo3y@zion.uk.xensource.com \
    --to=wei.liu2@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=Stewart.Hildebrand@dornerworks.com \
    --cc=cardoe@cardoe.com \
    --cc=christopher.w.clark@gmail.com \
    --cc=committers@xenproject.org \
    --cc=dpsmith.dev@gmail.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=james.mckenzie@bromium.com \
    --cc=jun.nakajima@intel.com \
    --cc=lars.kurth.xen@gmail.com \
    --cc=marmarek@invisiblethingslab.com \
    --cc=paul.durrant@citrix.com \
    --cc=robin.randhawa@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.