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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.01.18 at 12:33, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 08/01/18 08:22, Jan Beulich wrote:
>>>>> 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.
> 
> How would you suggest we build this then?  There seem to be no good options.

The answer to this is (I think) implied by the answer below (taken
together with what I've said earlier and is still visible above).

>>> 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.
> 
> Its in firmware, because of $(XENFIRMWAREDIR), which will be needed for
> anyone packaging this for distros.

Yes and no. My general assumption on how to utilize this on older
Xen is to build the shim from 4.10 (or newer), which means the
two trees will be distinct anyway. Therefore I think the better
approach will be to hand a pre-built xen-shim to the tools part of
the build, just like you can hand in pre-built ("system") SeaBIOS
or alike. No need to introduce an incompletely dependency
tracked sub-make.

> The separate .config is simply because we can.  There is no point
> wasting RAM in production system by using a fully-fat Xen binary when we
> can reasonably compile things out.

Of course, but that doesn't address my question regarding the
long term utility of the "all-in-one" binary that I had asked.

Jan


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