[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 2/15/19 4:35 AM, George Dunlap wrote:
>> On Feb 13, 2019, at 7:11 PM, Stefano Stabellini <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:
>>>> 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.

Daniel P. Smith

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.