Enhancing Xen's Kconfig infrastructure to support tailored solutions

Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Daniel P. Smith]

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.

V/r,
Daniel P. Smith
Apertus Solutions, LLC

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Jan Beulich]

>>> On 13.02.19 at 03:34, <dpsmith.dev@gmail.com> wrote:
> 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.

In EXPERT mode, tailoring is already possible to a certain degree,
and personally I don't see why this couldn't become more fine
grained. EXPERT mode, however, is being disliked in general, first
and foremost due to how one needs to enable it (and keep it
enabled).

To move away from a model where only a very limited set of
configurations is security supported, the original question would
need to be addressed: How could such a variety remain
manageable both in terms of testing and in terms of the handling
of bug reports? randconfig build testing is a small piece here, but
since it ensures successful builds only, it doesn't go quite far
enough. Plus, of course, the more variations are possible, the
longer it would take for even just a build issue to be noticed.

Jan



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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Wei Liu]

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.

Wei.

> V/r,
> Daniel P. Smith
> Apertus Solutions, LLC

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

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.

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Jan Beulich]

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

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

Jan



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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

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


Do you have any other suggestions about things that could be removed to
reach down to 100K LOC, in addition to what you have already written
above (Intel/AMD, shadow)?

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Andrew Cooper]

On 14/02/2019 18:32, Stefano Stabellini 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.

Drivers for the PIT/PIC are tiny, and they are the only ones which might
plausibly be able to drop.

There is only really one interrupt controller in x86, and it hasn't
changed much since the 486.

~Andrew

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Jan Beulich]

>>> On 14.02.19 at 19:57, <andrew.cooper3@citrix.com> wrote:
> There is only really one interrupt controller in x86, and it hasn't
> changed much since the 486.

Well, restricting ourselves to just x2APIC would perhaps remove
some code, but not all that much.

Jan



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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 4930 bytes --]



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

[-- Attachment #1.2: Type: text/html, Size: 23015 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Wei Liu]

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5415 bytes --]

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

See my attached .config

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1543 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Xen/x86 4.12.0-rc Configuration
#
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"

#
# Architecture Features
#
CONFIG_NR_CPUS=8
# CONFIG_PV is not set
CONFIG_HVM=y
# CONFIG_SHADOW_PAGING is not set
# CONFIG_BIGMEM is not set
# CONFIG_HVM_FEP is not set
CONFIG_TBOOT=y
# CONFIG_XEN_GUEST is not set

#
# Common Features
#
CONFIG_COMPAT=y
CONFIG_CORE_PARKING=y
CONFIG_HAS_ALTERNATIVE=y
CONFIG_HAS_EX_TABLE=y
CONFIG_MEM_ACCESS_ALWAYS_ON=y
CONFIG_MEM_ACCESS=y
CONFIG_HAS_MEM_PAGING=y
CONFIG_HAS_MEM_SHARING=y
CONFIG_HAS_PDX=y
CONFIG_HAS_UBSAN=y
CONFIG_HAS_KEXEC=y
CONFIG_HAS_GDBSX=y
CONFIG_HAS_IOPORTS=y
CONFIG_NEEDS_LIBELF=y
# CONFIG_KEXEC is not set
CONFIG_XENOPROF=y
# CONFIG_XSM is not set
CONFIG_SCHED_CREDIT=y
CONFIG_SCHED_CREDIT2=y
CONFIG_SCHED_RTDS=y
# CONFIG_SCHED_ARINC653 is not set
CONFIG_SCHED_NULL=y
CONFIG_SCHED_DEFAULT="credit2"
CONFIG_CRYPTO=y
# CONFIG_LIVEPATCH is not set
# CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set
CONFIG_CMDLINE=""
CONFIG_DOM0_MEM=""

#
# Device Drivers
#
CONFIG_ACPI=y
CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
CONFIG_NUMA=y
CONFIG_HAS_NS16550=y
CONFIG_HAS_EHCI=y
CONFIG_HAS_CPUFREQ=y
CONFIG_HAS_PASSTHROUGH=y
CONFIG_HAS_PCI=y
# CONFIG_VGA is not set
CONFIG_HAS_VPCI=y

#
# Deprecated Functionality
#
CONFIG_DEFCONFIG_LIST="arch/x86/configs/x86_64_defconfig"
CONFIG_ARCH_SUPPORTS_INT128=y

#
# Debugging Options
#
# CONFIG_DEBUG is not set

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Wei Liu]

On Fri, Feb 15, 2019 at 11:08:41AM -0800, Stefano Stabellini wrote:
[...]
> > 
> > Not sure how Stefano got the 157k number. Here are some results from
> > staging.
> 
> See my attached .config

I see. So these are non-debug builds. I have rerun with your config.

* HVM only -- Stefano's config

cloc --list-file=/tmp/tmp.QiL6SOYZeE
     329 text files.
     322 unique files.                           
       5 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.90 s (356.0 files/s, 244295.6 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                              303          32750          29021         153649
Assembly                        16            476            710           2320
-------------------------------------------------------------------------------
SUM:                           319          33226          29731         155969
-------------------------------------------------------------------------------
rm /tmp/tmp.QiL6SOYZeE

* PV only

cloc --list-file=/tmp/tmp.xa0YAQ1zuO
     284 text files.
     281 unique files.                           
       3 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.52 s (534.8 files/s, 338743.5 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                              265          26009          23755         123911
Assembly                        15            469            701           2518
-------------------------------------------------------------------------------
SUM:                           280          26478          24456         126429
-------------------------------------------------------------------------------
rm /tmp/tmp.xa0YAQ1zuO


* Full build

cloc --list-file=/tmp/tmp.fZyrQI4xdL
     348 text files.
     341 unique files.                           
       5 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.66 s (514.6 files/s, 343139.6 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                              320          33626          29835         157983
Assembly                        18            513            771           2675
-------------------------------------------------------------------------------
SUM:                           338          34139          30606         160658
-------------------------------------------------------------------------------
rm /tmp/tmp.fZyrQI4xdL


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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
Lars

> On 18 Feb 2019, at 11:12, Wei Liu <wei.liu2@citrix.com> wrote:
> 
> On Fri, Feb 15, 2019 at 11:08:41AM -0800, Stefano Stabellini wrote:
> [...]
>>> 
>>> Not sure how Stefano got the 157k number. Here are some results from
>>> staging.
>> 
>> See my attached .config
> 
> I see. So these are non-debug builds. I have rerun with your config.
> 
> * HVM only -- Stefano's config
> 
> cloc --list-file=/tmp/tmp.QiL6SOYZeE
>     329 text files.
>     322 unique files.                           
>       5 files ignored.
> 
> github.com/AlDanial/cloc v 1.70  T=0.90 s (356.0 files/s, 244295.6 lines/s)
> -------------------------------------------------------------------------------
> Language                     files          blank        comment           code
> -------------------------------------------------------------------------------
> C                              303          32750          29021         153649
> Assembly                        16            476            710           2320
> -------------------------------------------------------------------------------
> SUM:                           319          33226          29731         155969
> -------------------------------------------------------------------------------
> rm /tmp/tmp.QiL6SOYZeE
> 
> * PV only
> 
> cloc --list-file=/tmp/tmp.xa0YAQ1zuO
>     284 text files.
>     281 unique files.                           
>       3 files ignored.
> 
> github.com/AlDanial/cloc v 1.70  T=0.52 s (534.8 files/s, 338743.5 lines/s)
> -------------------------------------------------------------------------------
> Language                     files          blank        comment           code
> -------------------------------------------------------------------------------
> C                              265          26009          23755         123911
> Assembly                        15            469            701           2518
> -------------------------------------------------------------------------------
> SUM:                           280          26478          24456         126429
> -------------------------------------------------------------------------------
> rm /tmp/tmp.xa0YAQ1zuO
> 
> 
> * Full build
> 
> cloc --list-file=/tmp/tmp.fZyrQI4xdL
>     348 text files.
>     341 unique files.                           
>       5 files ignored.
> 
> github.com/AlDanial/cloc v 1.70  T=0.66 s (514.6 files/s, 343139.6 lines/s)
> -------------------------------------------------------------------------------
> Language                     files          blank        comment           code
> -------------------------------------------------------------------------------
> C                              320          33626          29835         157983
> Assembly                        18            513            771           2675
> -------------------------------------------------------------------------------
> SUM:                           338          34139          30606         160658
> -------------------------------------------------------------------------------
> rm /tmp/tmp.fZyrQI4xdL
> 


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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Wei Liu]

On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
> Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
> Lars

The cloc target counts the files in the dependency graph generated by
make. A lot of the files contain both common x86 code and PV only code.
So an HVM only build will count some of the PV code.

Also, I think HVM code is rather complex in its own right.

Wei.

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[George Dunlap]

On 2/18/19 11:23 AM, Wei Liu wrote:
> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
>> Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
>> Lars
> 
> The cloc target counts the files in the dependency graph generated by
> make. A lot of the files contain both common x86 code and PV only code.
> So an HVM only build will count some of the PV code.

Still, what that shows is that there have been nearly 25k likes of code
identified as "HVM-only", while there have been less than 5k likes of
code identified as "PV-only".  That's quite a bit more lopsided than I
was expecting.

Perhaps part of the explanation is that PV came first, and HVM
afterwards; and the core "Xen" interfaces (grant tables, &c) are the
same between the two.  That is, HVM guests (if we include PVH dom0) have
the vast majority of functionality available to PV guests, while there
are large sections of functionality available to HVM guests to which PV
guests have no access.

 -George

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 18 Feb 2019, at 11:30, George Dunlap <george.dunlap@citrix.com> wrote:
> 
> On 2/18/19 11:23 AM, Wei Liu wrote:
>> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
>>> Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
>>> Lars
>> 
>> The cloc target counts the files in the dependency graph generated by
>> make.

Do we know for sure that CLOC counts everything in a file or does it honour the pre-processor settings?

>> A lot of the files contain both common x86 code and PV only code.
>> So an HVM only build will count some of the PV code.
> 
> Still, what that shows is that there have been nearly 25k likes of code
> identified as "HVM-only", while there have been less than 5k likes of
> code identified as "PV-only".  That's quite a bit more lopsided than I
> was expecting.

I was thinking the same

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Wei Liu]

On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
> 
> 
> > On 18 Feb 2019, at 11:30, George Dunlap <george.dunlap@citrix.com> wrote:
> > 
> > On 2/18/19 11:23 AM, Wei Liu wrote:
> >> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
> >>> Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
> >>> Lars
> >> 
> >> The cloc target counts the files in the dependency graph generated by
> >> make.
> 
> Do we know for sure that CLOC counts everything in a file or does it honour the pre-processor settings?

We certainly don't feed any preprocessor defines to it. I doubt it
understand C to that level of details anyway.

Wei.

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 18 Feb 2019, at 11:57, Wei Liu <wei.liu2@citrix.com> wrote:
> 
> On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>> 
>> 
>>> On 18 Feb 2019, at 11:30, George Dunlap <george.dunlap@citrix.com> wrote:
>>> 
>>> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
>>>>> Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
>>>>> Lars
>>>> 
>>>> The cloc target counts the files in the dependency graph generated by
>>>> make.
>> 
>> Do we know for sure that CLOC counts everything in a file or does it honour the pre-processor settings?
> 
> We certainly don't feed any preprocessor defines to it. I doubt it
> understand C to that level of details anyway.

That is interesting, because essentially the CLOC counts provide an upper bound instead the real lines of code. So in reality, both the Arm and x86 configs may turn out to be lower than we thought
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Andrew Cooper]

On 18/02/2019 11:57, Wei Liu wrote:
> On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>>
>>> On 18 Feb 2019, at 11:30, George Dunlap <george.dunlap@citrix.com> wrote:
>>>
>>> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
>>>>> Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
>>>>> Lars
>>>> The cloc target counts the files in the dependency graph generated by
>>>> make.
>> Do we know for sure that CLOC counts everything in a file or does it honour the pre-processor settings?
> We certainly don't feed any preprocessor defines to it. I doubt it
> understand C to that level of details anyway.

LoC isn't a fantastic metric under any circumstance.

Bigger code is definitely better, if the reason it is bigger is because
it is because it is formatted for readability/clarity etc.

Attempting to optimise for smaller LoC, other than making entire
functional areas optional, is usually short sighted.

~Andrew

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 18 Feb 2019, at 12:01, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> 
> On 18/02/2019 11:57, Wei Liu wrote:
>> On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>>> 
>>>> On 18 Feb 2019, at 11:30, George Dunlap <george.dunlap@citrix.com> wrote:
>>>> 
>>>> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>>> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
>>>>>> Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
>>>>>> Lars
>>>>> The cloc target counts the files in the dependency graph generated by
>>>>> make.
>>> Do we know for sure that CLOC counts everything in a file or does it honour the pre-processor settings?
>> We certainly don't feed any preprocessor defines to it. I doubt it
>> understand C to that level of details anyway.
> 
> LoC isn't a fantastic metric under any circumstance.
> 
> Bigger code is definitely better, if the reason it is bigger is because
> it is because it is formatted for readability/clarity etc.

I don't disagree. A measure such as Logical Lines Of Code may be more appropriate longer term, as it removes the formatting/readability aspect. 

> Attempting to optimise for smaller LoC, other than making entire
> functional areas optional, is usually short sighted.

Agreed. 

We are basically using the SLOC figure as a proxy for "potential cost of safety certification" at least for Arm
I was hoping the results were clearer and I could use the figures to illustrate the impact of a PV or HVM only build to illustrate the safety impact, but maybe I should stay clear of this.

Regards
Lars



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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[George Dunlap]

On 2/18/19 12:01 PM, Andrew Cooper wrote:
> On 18/02/2019 11:57, Wei Liu wrote:
>> On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>>>
>>>> On 18 Feb 2019, at 11:30, George Dunlap <george.dunlap@citrix.com> wrote:
>>>>
>>>> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>>> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
>>>>>> Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
>>>>>> Lars
>>>>> The cloc target counts the files in the dependency graph generated by
>>>>> make.
>>> Do we know for sure that CLOC counts everything in a file or does it honour the pre-processor settings?
>> We certainly don't feed any preprocessor defines to it. I doubt it
>> understand C to that level of details anyway.
> 
> LoC isn't a fantastic metric under any circumstance.
> 
> Bigger code is definitely better, if the reason it is bigger is because
> it is because it is formatted for readability/clarity etc.
> 
> Attempting to optimise for smaller LoC, other than making entire
> functional areas optional, is usually short sighted.

For instance, we could probably decrease the LoC by nearly 20k by
changing the style not to give the opening bracket its own line:

$ find . -name '*.c' | xargs grep '^[[:space:]]*{' | wc -l
19896
$ find . -name '*.[ch]' | xargs grep '^[[:space:]]*{' | wc -l
21847

 -George

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[George Dunlap]

On 2/18/19 12:11 PM, George Dunlap wrote:
> On 2/18/19 12:01 PM, Andrew Cooper wrote:
>> On 18/02/2019 11:57, Wei Liu wrote:
>>> On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>>>>
>>>>> On 18 Feb 2019, at 11:30, George Dunlap <george.dunlap@citrix.com> wrote:
>>>>>
>>>>> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>>>> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
>>>>>>> Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
>>>>>>> Lars
>>>>>> The cloc target counts the files in the dependency graph generated by
>>>>>> make.
>>>> Do we know for sure that CLOC counts everything in a file or does it honour the pre-processor settings?
>>> We certainly don't feed any preprocessor defines to it. I doubt it
>>> understand C to that level of details anyway.
>>
>> LoC isn't a fantastic metric under any circumstance.
>>
>> Bigger code is definitely better, if the reason it is bigger is because
>> it is because it is formatted for readability/clarity etc.
>>
>> Attempting to optimise for smaller LoC, other than making entire
>> functional areas optional, is usually short sighted.
> 
> For instance, we could probably decrease the LoC by nearly 20k by
> changing the style not to give the opening bracket its own line:
> 
> $ find . -name '*.c' | xargs grep '^[[:space:]]*{' | wc -l
> 19896
> $ find . -name '*.[ch]' | xargs grep '^[[:space:]]*{' | wc -l
> 21847

This is hypervisor only BTW (run from xen.git/xen).

It is a bit mind-boggling to think that there are more open brackets in
the Xen code base than there is PV-specific code. O_o

 -George

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 1897 bytes --]



> On 18 Feb 2019, at 12:16, George Dunlap <george.dunlap@citrix.com> wrote:
> 
> On 2/18/19 12:11 PM, George Dunlap wrote:
>> On 2/18/19 12:01 PM, Andrew Cooper wrote:
>>> On 18/02/2019 11:57, Wei Liu wrote:
>>>> On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>>>>> 
>>>>>> On 18 Feb 2019, at 11:30, George Dunlap <george.dunlap@citrix.com> wrote:
>>>>>> 
>>>>>> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>>>>> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
>>>>>>>> Thank you Wei. It's interesting though that the full vs HVM only is almost identical in terms of SLOC's
>>>>>>>> Lars
>>>>>>> The cloc target counts the files in the dependency graph generated by
>>>>>>> make.
>>>>> Do we know for sure that CLOC counts everything in a file or does it honour the pre-processor settings?
>>>> We certainly don't feed any preprocessor defines to it. I doubt it
>>>> understand C to that level of details anyway.
>>> 
>>> LoC isn't a fantastic metric under any circumstance.
>>> 
>>> Bigger code is definitely better, if the reason it is bigger is because
>>> it is because it is formatted for readability/clarity etc.
>>> 
>>> Attempting to optimise for smaller LoC, other than making entire
>>> functional areas optional, is usually short sighted.
>> 
>> For instance, we could probably decrease the LoC by nearly 20k by
>> changing the style not to give the opening bracket its own line:
>> 
>> $ find . -name '*.c' | xargs grep '^[[:space:]]*{' | wc -l
>> 19896
>> $ find . -name '*.[ch]' | xargs grep '^[[:space:]]*{' | wc -l
>> 21847
> 
> This is hypervisor only BTW (run from xen.git/xen).
> 
> It is a bit mind-boggling to think that there are more open brackets in
> the Xen code base than there is PV-specific code. O_o

As we have the same coding conventions across hypervisor code, that shouldn't make a difference

Lars

[-- Attachment #1.2: Type: text/html, Size: 6890 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

On Mon, 18 Feb 2019, Lars Kurth wrote:
>       On 18 Feb 2019, at 12:16, George Dunlap <george.dunlap@citrix.com> wrote:
> 
> On 2/18/19 12:11 PM, George Dunlap wrote:
>       On 2/18/19 12:01 PM, Andrew Cooper wrote:
>             On 18/02/2019 11:57, Wei Liu wrote:
>                   On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
> 
>                               On 18 Feb 2019, at 11:30, George Dunlap
>                               <george.dunlap@citrix.com> wrote:
> 
>                               On 2/18/19 11:23 AM, Wei Liu wrote:
>                                     On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars
>                                     Kurth wrote:
>                                           Thank you Wei. It's interesting though
>                                           that the full vs HVM only is almost
>                                           identical in terms of SLOC's
>                                           Lars
> 
>                                     The cloc target counts the files in the dependency
>                                     graph generated by
>                                     make.
> 
>                         Do we know for sure that CLOC counts everything in a file or does it honour
>                         the pre-processor settings?
> 
>                   We certainly don't feed any preprocessor defines to it. I doubt it
>                   understand C to that level of details anyway.
> 
> 
>             LoC isn't a fantastic metric under any circumstance.
> 
>             Bigger code is definitely better, if the reason it is bigger is because
>             it is because it is formatted for readability/clarity etc.
> 
>             Attempting to optimise for smaller LoC, other than making entire
>             functional areas optional, is usually short sighted.
> 
> 
>       For instance, we could probably decrease the LoC by nearly 20k by
>       changing the style not to give the opening bracket its own line:
> 
>       $ find . -name '*.c' | xargs grep '^[[:space:]]*{' | wc -l
>       19896
>       $ find . -name '*.[ch]' | xargs grep '^[[:space:]]*{' | wc -l
>       21847
> 
> 
> This is hypervisor only BTW (run from xen.git/xen).
> 
> It is a bit mind-boggling to think that there are more open brackets in
> the Xen code base than there is PV-specific code. O_o
> 
> 
> As we have the same coding conventions across hypervisor code, that shouldn't make a difference

This is amazing, in a terrible kind of way: all our numbers will be
inflated by 20K!! For Xen on Arm is almost 50%! I am half-thinking we
should add xargs grep '^[[:space:]]*{' to the make cloc target.

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[P S]

[-- Attachment #1.1: Type: text/plain, Size: 3409 bytes --]

On Feb 19, 2019, at 14:13, Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
>> On Mon, 18 Feb 2019, Lars Kurth wrote:
>>      On 18 Feb 2019, at 12:16, George Dunlap <george.dunlap@citrix.com> wrote:
>> 
>> On 2/18/19 12:11 PM, George Dunlap wrote:
>>      On 2/18/19 12:01 PM, Andrew Cooper wrote:
>>            On 18/02/2019 11:57, Wei Liu wrote:
>>                  On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>> 
>>                              On 18 Feb 2019, at 11:30, George Dunlap
>>                              <george.dunlap@citrix.com> wrote:
>> 
>>                              On 2/18/19 11:23 AM, Wei Liu wrote:
>>                                    On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars
>>                                    Kurth wrote:
>>                                          Thank you Wei. It's interesting though
>>                                          that the full vs HVM only is almost
>>                                          identical in terms of SLOC's
>>                                          Lars
>> 
>>                                    The cloc target counts the files in the dependency
>>                                    graph generated by
>>                                    make.
>> 
>>                        Do we know for sure that CLOC counts everything in a file or does it honour
>>                        the pre-processor settings?
>> 
>>                  We certainly don't feed any preprocessor defines to it. I doubt it
>>                  understand C to that level of details anyway.
>> 
>> 
>>            LoC isn't a fantastic metric under any circumstance.
>> 
>>            Bigger code is definitely better, if the reason it is bigger is because
>>            it is because it is formatted for readability/clarity etc.
>> 
>>            Attempting to optimise for smaller LoC, other than making entire
>>            functional areas optional, is usually short sighted.
>> 
>> 
>>      For instance, we could probably decrease the LoC by nearly 20k by
>>      changing the style not to give the opening bracket its own line:
>> 
>>      $ find . -name '*.c' | xargs grep '^[[:space:]]*{' | wc -l
>>      19896
>>      $ find . -name '*.[ch]' | xargs grep '^[[:space:]]*{' | wc -l
>>      21847
>> 
>> 
>> This is hypervisor only BTW (run from xen.git/xen).
>> 
>> It is a bit mind-boggling to think that there are more open brackets in
>> the Xen code base than there is PV-specific code. O_o
>> 
>> 
>> As we have the same coding conventions across hypervisor code, that shouldn't make a difference
> 
> This is amazing, in a terrible kind of way: all our numbers will be
> inflated by 20K!! For Xen on Arm is almost 50%! I am half-thinking we
> should add xargs grep '^[[:space:]]*{' to the make cloc target.

UCC (Unified Code Count) [1] can measure/diff logical SLOC for several languages.

Rich

[1] Papers 
http://csse.usc.edu/TECHRPTS/2007/usc-csse-2007-737/usc-csse-2007-737.pdf
http://csse.usc.edu/csse/event/2012/COCOMO/presentations/TOR-2010(3906)-72_Library.pdf
http://www.nguyenvvu.net/wp-content/uploads/2015/07/UCC_Tool_Description.pdf

[2] Source
http://csse.usc.edu/ucc_new/wordpress/2018/07/26/ucc-version-2018-07/

[3] Build
g++ ./src/*.cpp -o UCC -std=c++0x -DUNIX -O3

[4] Run
UCC -dir xen *.c -outdir report


[-- Attachment #1.2: Type: text/html, Size: 10453 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Jan Beulich]

>>> On 14.02.19 at 19:32, <sstabellini@kernel.org> wrote:
> Do you have any other suggestions about things that could be removed to
> reach down to 100K LOC, in addition to what you have already written
> above (Intel/AMD, shadow)?

If you mean ones we already have Kconfig options for, then you
could drop TBOOT, which in turn drops CRYPTO, which together
is about 3k LOC. Turning off XENOPROF would yield another 2k.
I assume you've already restricted yourself to just the null
scheduler? But that's about it, I think, without actual code (or at
least Kconfig) changes.

Jan



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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

On Fri, 15 Feb 2019, Jan Beulich wrote:
> >>> On 14.02.19 at 19:32, <sstabellini@kernel.org> wrote:
> > Do you have any other suggestions about things that could be removed to
> > reach down to 100K LOC, in addition to what you have already written
> > above (Intel/AMD, shadow)?
> 
> If you mean ones we already have Kconfig options for, then you
> could drop TBOOT, which in turn drops CRYPTO, which together
> is about 3k LOC. Turning off XENOPROF would yield another 2k.
> I assume you've already restricted yourself to just the null
> scheduler? But that's about it, I think, without actual code (or at
> least Kconfig) changes.

I meant suggestions for things that could be disabled in the build, but
we don't have a kconfig option for it yet. Such as some of the
decompression algorithms (as Wei pointed out).

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Wei Liu]

On Thu, Feb 14, 2019 at 10:32:31AM -0800, Stefano Stabellini wrote:
> 
> Do you have any other suggestions about things that could be removed to
> reach down to 100K LOC, in addition to what you have already written
> above (Intel/AMD, shadow)?

Turning off some of the decompression algorithms can probably save you
somewhere between 1K to 4K LOC.

This requires some code changes though.

Wei.

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Andrew Cooper]

On 14/02/2019 09:53, 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

This was always the longterm plan, after making CONFIG_{PV,HVM} work
(thanks Wei!).

Not because I expect many people to disable them in production builds,
but because it is an excellent way for CI/Randconfig to enforce that we
keep our vendor neutral and vendor specific code cleanly separated.

> 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 agree this is harder.  One area where we could already make a
substantial chunk of cleanup is to drop the final remnants of the UP
boot, and pre-APIC hardware.  We're long past this already, since
dropping the 32bit hypervisor build.

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

There are perhaps some improvements which could be made by compiling out
support for older generations of VT-x/SVM (dropping pre-Westmere Intel
hardware which allows us to depend on the unrestricted_guest feature in
hardware), but I suspect we are getting into diminishing returns here.

~Andrew

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[George Dunlap]

> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini <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.

I think one thing that might be helpful is a sort of “feature document” for each defconfig we’re looking at creating.  This would include:

* What the “target use case” for each defconfig would be
* The end goal in terms of functionality / LoC / whatever
* The current state, work items yet to do
* What potential variations there are (i.e., how to enable shadow if you want, or switch from Intel-only to AMD-only)

I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying where we want to go, and moving things from “to do” to “done” as they get implemented.  That would make it easier to have in-progress things in the tree, make it easier for people to collaborate / enhance defconfigs, and also be a starting point for talking about testing and support status.

 -George

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 15 Feb 2019, at 09:35, George Dunlap <George.Dunlap@citrix.com> wrote:
> 
>>> 
>>> 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.
> 
> I think one thing that might be helpful is a sort of “feature document” for each defconfig we’re looking at creating.  This would include:
> 
> * What the “target use case” for each defconfig would be
> * The end goal in terms of functionality / LoC / whatever
> * The current state, work items yet to do
> * What potential variations there are (i.e., how to enable shadow if you want, or switch from Intel-only to AMD-only)
> 
> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying where we want to go, and moving things from “to do” to “done” as they get implemented.  That would make it easier to have in-progress things in the tree, make it easier for people to collaborate / enhance defconfigs, and also be a starting point for talking about testing and support status.

I think this is a great idea
Regards
Lars


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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3715 bytes --]

On Fri, 15 Feb 2019, George Dunlap wrote:
> > On Feb 13, 2019, at 7:11 PM, Stefano Stabellini <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.
> 
> I think one thing that might be helpful is a sort of “feature document” for each defconfig we’re looking at creating.  This would include:
> 
> * What the “target use case” for each defconfig would be
> * The end goal in terms of functionality / LoC / whatever
> * The current state, work items yet to do
> * What potential variations there are (i.e., how to enable shadow if you want, or switch from Intel-only to AMD-only)
> 
> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying where we want to go, and moving things from “to do” to “done” as they get implemented.  That would make it easier to have in-progress things in the tree, make it easier for people to collaborate / enhance defconfigs, and also be a starting point for talking about testing and support status.

+1

Just to set the expectations right on this thread: I am just trying to
provide feedback from the field, things I know are important to the Xen
on x86 embedded user community. I am not going to take this on as a work
item.  But somebody else might? Daniel Smith, I am looking at you :-)

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[George Dunlap]

> On Feb 15, 2019, at 5:36 PM, Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
> On Fri, 15 Feb 2019, George Dunlap wrote:
>>> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini <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.
>> 
>> I think one thing that might be helpful is a sort of “feature document” for each defconfig we’re looking at creating.  This would include:
>> 
>> * What the “target use case” for each defconfig would be
>> * The end goal in terms of functionality / LoC / whatever
>> * The current state, work items yet to do
>> * What potential variations there are (i.e., how to enable shadow if you want, or switch from Intel-only to AMD-only)
>> 
>> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying where we want to go, and moving things from “to do” to “done” as they get implemented.  That would make it easier to have in-progress things in the tree, make it easier for people to collaborate / enhance defconfigs, and also be a starting point for talking about testing and support status.
> 
> +1
> 
> Just to set the expectations right on this thread: I am just trying to
> provide feedback from the field, things I know are important to the Xen
> on x86 embedded user community. I am not going to take this on as a work
> item.  But somebody else might? Daniel Smith, I am looking at you :-)

I tried to make this clear on the call, but just in case, let me try to repeat / expand on what I said:

When creating a brand-new thing like this, the best thing is for each person/org to make exactly the thing that they want.  Daniel shouldn’t be trying to make a defconfig for embedded x86 hypervisors unless that’s specifically what he wants to use: he should be making a defconfig for his specific use case.

When someone else comes along and wants the second instance of whatever this thing is, we can then refactor our system based on two people’s real actual requirements.

The only time to try to sit and plan a General Purpose Thing are:
1. When you already have loads of instances, so you have a clear idea what a General Purpose Thing of this type looks like
2. When you need to worry about backwards compatibility.

I don’t think #1 or #2 are true in this case; so the most efficient thing will be for Daniel to make exactly the thing that he himself wants, spending very little time on attempting to make it a General Purpose Thing that someone else might want.

 -George

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5884 bytes --]

On Fri, 15 Feb 2019, George Dunlap wrote:
> > On Feb 15, 2019, at 5:36 PM, Stefano Stabellini <sstabellini@kernel.org> wrote:
> > 
> > On Fri, 15 Feb 2019, George Dunlap wrote:
> >>> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini <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.
> >> 
> >> I think one thing that might be helpful is a sort of “feature document” for each defconfig we’re looking at creating.  This would include:
> >> 
> >> * What the “target use case” for each defconfig would be
> >> * The end goal in terms of functionality / LoC / whatever
> >> * The current state, work items yet to do
> >> * What potential variations there are (i.e., how to enable shadow if you want, or switch from Intel-only to AMD-only)
> >> 
> >> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying where we want to go, and moving things from “to do” to “done” as they get implemented.  That would make it easier to have in-progress things in the tree, make it easier for people to collaborate / enhance defconfigs, and also be a starting point for talking about testing and support status.
> > 
> > +1
> > 
> > Just to set the expectations right on this thread: I am just trying to
> > provide feedback from the field, things I know are important to the Xen
> > on x86 embedded user community. I am not going to take this on as a work
> > item.  But somebody else might? Daniel Smith, I am looking at you :-)
> 
> I tried to make this clear on the call, but just in case, let me try to repeat / expand on what I said:
> 
> When creating a brand-new thing like this, the best thing is for each person/org to make exactly the thing that they want.  Daniel shouldn’t be trying to make a defconfig for embedded x86 hypervisors unless that’s specifically what he wants to use: he should be making a defconfig for his specific use case.
> 
> When someone else comes along and wants the second instance of whatever this thing is, we can then refactor our system based on two people’s real actual requirements.
> 
> The only time to try to sit and plan a General Purpose Thing are:
> 1. When you already have loads of instances, so you have a clear idea what a General Purpose Thing of this type looks like
> 2. When you need to worry about backwards compatibility.
> 
> I don’t think #1 or #2 are true in this case; so the most efficient thing will be for Daniel to make exactly the thing that he himself wants, spending very little time on attempting to make it a General Purpose Thing that someone else might want.

Daniel started this thread with the following statement:

  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.

That's what I was trying to do :-)

Also, I have already enhanced the build and reduced the total LOC count
in Xen 4.12 to less than 50K for Xilinx MPSoC. My comment that "I am not
going to take this on" refers to the x86 side of things. We can
certainly work together on components that are common.

And from what I understood the x86 embedded use-case I was trying to
highlight is a decent stepping stone toward Daniel's own kconfig
enhancement goals.

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

Re: Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Daniel P. Smith]

On 2/15/19 4:35 AM, George Dunlap wrote:
> 
> 
>> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini <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:
<snip>
>>>> 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.
> 
> I think one thing that might be helpful is a sort of “feature document” for each defconfig we’re looking at creating.  This would include:
> 
> * What the “target use case” for each defconfig would be
> * The end goal in terms of functionality / LoC / whatever
> * The current state, work items yet to do
> * What potential variations there are (i.e., how to enable shadow if you want, or switch from Intel-only to AMD-only)
> 
> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying where we want to go, and moving things from “to do” to “done” as they get implemented.  That would make it easier to have in-progress things in the tree, make it easier for people to collaborate / enhance defconfigs, and also be a starting point for talking about testing and support status.

First let me thank you and everyone else for the comments on the call,
it is greatly appreciated. Yes, my intent was to start with a design doc
patch to /docs/design/defconfig/"first-kconfig-configuration.md". One of
the reasons that I wanted to solicit community input vice just crafting
a design purely around my use case was due to what I have found is a
general interest in expanding (albeit in a controlled manner) the
Kconfig infrastructure. In my use case I am looking to be able to build
an L0 Xen kernel containing only the logic necessary to host a nested
hypervisor, e.g. KVM or HyperV. I would like to believe a better product
will be resultant if I try to be considerate of others' interest and
desires as I start to work on this. In addition, my use case is a bit
more complicated which will require time and care as I work through the
"how" and I expect to overlap with those looking for purely feature
reduction. This is why I made the statement on the call that Stefano's
IoT feature minimal, targeted hardware use case would be a good stepping
stone along the path to an L0 nested hosting hypervisor.


V/r,
Daniel P. Smith

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