Xen project Mailing List

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 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.

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