Re: [Xen-devel] [PATCH RFC v1 36/74] --- x86/shim: Kconfig and command line options

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.01.18 at 18:51, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 05/01/18 15:26, Jan Beulich wrote:
>>>>> On 04.01.18 at 14:05, <wei.liu2@xxxxxxxxxx> wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -133,6 +133,28 @@ config PVH_GUEST
>>>     ---help---
>>>       Support booting using the PVH ABI.
>>>  
>>> +     If unsure, say N.
>>> +
>>> +config PV_SHIM
>>> +   def_bool n
>>> +   prompt "PV Shim"
>>> +   depends on PV && XEN_GUEST
>>> +   ---help---
>>> +     Build Xen with a mode which acts as a shim to allow PV guest to run
>>> +     in an HVM/PVH container. This mode can only be enabled with command
>>> +     line option.
>>> +
>>> +     If unsure, say N.
>>> +
>>> +config PV_SHIM_EXCLUSIVE
>>> +   def_bool n
>>> +   prompt "PV Shim Exclusive"
>>> +   depends on PV_SHIM
>> My expectation so far was that this would be the only mode we
>> target, hence I think at the very least the default wants to be y
>> here.
> 
> Until proper out-of-tree Xen builds work, building the shim binary at
> all is a PITA.

Out-of-tree builds would certainly be nice to have, but I don't see
the big issue with building a shim-only binary, and I have been
explaining before how I build multiple distinct configurations from
the same source tree: Rather than building in the actual source
tree, establish a tree of symlinks back to the source tree, and
build in there. You can create any number of such trees. I'd also
expect this would eliminate some or all of the (I'm sorry) crude
build logic you're introducing in one of the patches; at the very
least I'm considering that patch so heavily draft/RFC that I didn't
even mean to reply to it.

> These defaults give a developer a single binary which is capable of
> running natively or as the shim, which has made development far more
> productive.  Its certainly the way I'd expect to do primary future
> development of the shim.

Interesting - the need to have the binary built under tools/firmware/
to me is a clear indication that you'll need a separate .config for it
anyway, so I can't see how building a universal binary will be of long
term help.

Jan


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