On Thu, Feb 14, 2019 at 09:03:24PM +0000, Lars Kurth wrote:
>
>
> > On 14 Feb 2019, at 18:32, Stefano Stabellini <[email protected]> wrote:
> >
> > On Thu, 14 Feb 2019, Jan Beulich wrote:
> >>>>> On 13.02.19 at 20:11, <[email protected]> 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
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
