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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/02/2019 09:53, Jan Beulich wrote:
>>>> On 13.02.19 at 20:11, <sstabellini@xxxxxxxxxx> wrote:
>> On Wed, 13 Feb 2019, Wei Liu wrote:
>>> On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
>>>> Greetings,
>>>>
>>>> On the 11/14/18 Xen x86 community call a discussion was initiated about
>>>> using Kconfig to build minimized versions of Xen for security, safety
>>>> and other certification requirements. After some offline discussions
>>>> with Xen contributors I realized that a variety of efforts each with
>>>> their own respective goals are underway,
>>>>
>>>>  - nested virtualization
>>>>  - mixed criticality architectures
>>>>  - reducing trusted componentary
>>>>  - combining hardware protection of virtualization with performance and
>>>> ease-of-use of containers
>>>>
>>>> These efforts use hypervisors in different roles, all which Xen is
>>>> capable of meeting. Today Xen's utility comes at the expense of carrying
>>>> features necessary for one role to be present in another role where it
>>>> is not required, e.g. PV interfaces that may not be essential in an ARM
>>>> mixed criticality deployment.
>>>>
>>>> The initial focus will be to explore and document the range of possible
>>>> use cases that are of interest to the Xen community. This will be the
>>>> input to a design document that is crafted in conjunction with the Xen
>>>> maintainers, to identify possible approaches to extend the existing
>>>> Kconfig infrastructure to produce tailored instances of Xen.
>>>>
>>>> If you are interested in participating in this effort, please reply to
>>>> this thread to outline possible use cases, design constraints and other
>>>> considerations for improving Xen's Kconfig infrastructure to support
>>>> tailoring for specific use cases.
>>>>
>>> My impression from the community call is that you want to provide
>>> smallish configurations for different use cases.
>>>
>>> The Kconfig infrastructure is already able to do what you want as far as
>>> I can tell.  You can easily feed it a base config file -- see files
>>> under automation/configs/x86/.  What sort of extension is needed in your
>>> opinion?
>>>
>>> As use case goes, it would be a good start if you just submit something
>>> you care about.
>> I mentioned on the call that a good first start could be a kconfig that
>> allows to build an hypervisor binary with only support for PVH and only
>> support for recent Intel machines, with the goal of minimizing the code
>> base to less than 100K LOC.
> "With only support for PVH" (which really means HVM) we already have.
> "With only support for recent Intel machines" would require adding new
> Kconfig options first, to control Intel, AMD, etc separately

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel