|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions
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@xxxxxxxxxx> wrote: >>> On Wed, 13 Feb 2019, Wei Liu wrote: >>>> On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote: >>>>> Greetings, >>>>> >>>>> On the 11/14/18 Xen x86 community call a discussion was initiated about >>>>> using Kconfig to build minimized versions of Xen for security, safety >>>>> and other certification requirements. After some offline discussions >>>>> with Xen contributors I realized that a variety of efforts each with >>>>> their own respective goals are underway, >>>>> >>>>> - nested virtualization >>>>> - mixed criticality architectures >>>>> - reducing trusted componentary >>>>> - combining hardware protection of virtualization with performance and >>>>> ease-of-use of containers >>>>> >>>>> These efforts use hypervisors in different roles, all which Xen is >>>>> capable of meeting. Today Xen's utility comes at the expense of carrying >>>>> features necessary for one role to be present in another role where it >>>>> is not required, e.g. PV interfaces that may not be essential in an ARM >>>>> mixed criticality deployment. >>>>> >>>>> The initial focus will be to explore and document the range of possible >>>>> use cases that are of interest to the Xen community. This will be the >>>>> input to a design document that is crafted in conjunction with the Xen >>>>> maintainers, to identify possible approaches to extend the existing >>>>> Kconfig infrastructure to produce tailored instances of Xen. >>>>> >>>>> If you are interested in participating in this effort, please reply to >>>>> this thread to outline possible use cases, design constraints and other >>>>> considerations for improving Xen's Kconfig infrastructure to support >>>>> tailoring for specific use cases. >>>>> >>>> My impression from the community call is that you want to provide >>>> smallish configurations for different use cases. >>>> >>>> The Kconfig infrastructure is already able to do what you want as far as >>>> I can tell. You can easily feed it a base config file -- see files >>>> under automation/configs/x86/. What sort of extension is needed in your >>>> opinion? >>>> >>>> As use case goes, it would be a good start if you just submit something >>>> you care about. >>> I mentioned on the call that a good first start could be a kconfig that >>> allows to build an hypervisor binary with only support for PVH and only >>> support for recent Intel machines, with the goal of minimizing the code >>> base to less than 100K LOC. >> "With only support for PVH" (which really means HVM) we already have. >> "With only support for recent Intel machines" would require adding new >> Kconfig options first, to control Intel, AMD, etc separately, and to then >> further somehow separate "old" from "new" (which may turn out not >> very easy to do without a lot of #ifdef-ary or other code churn). I'm >> not aware of something like this existing on Linux either - all I'm aware >> of there is a means to control what -m<arch> option might be passed >> to the compiler, but without disabling any source code from getting >> compiled. > I was thinking along the lines of having options to disable drivers for > older timers and older interrupt controllers that are not needed on > recent machines. 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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |