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 <sstabell...@kernel.org>
> > > wrote:
> > >
> > > On Thu, 14 Feb 2019, Jan Beulich wrote:
> > >>>>> On 13.02.19 at 20:11, <sstabell...@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
#
# 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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel