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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

>
>> 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.

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.

~Andrew

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