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
next prev parent 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.