Re: [Xen-devel] [PATCH v2 21/23] x86: expose CONFIG_HVM

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.08.18 at 22:09, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 30/08/18 07:21, Jan Beulich wrote:
>>>>>>> +
>>>>>>> +         If unsure, say Y.
>>>>>>> +
>>>>>>>  
>>>>>>>  config SHADOW_PAGING
>>>>>> No double blank lines please.
>>>>>>
>>>>>> My previously voiced reservations wrt the shim remain. I continue
>>>>>> to disagree with Andrew that the symbol needs to be visible in a
>>>>>> shim-only config, and I continue to demand as a minimum that the
>>>>>> default here be N in that case if the symbol really is to remain visible.
>>>>> Conditionally influencing the default is fine.  Hiding the symbol is not.
>>>>>
>>>>> To be very very clear, I will nack/revert any patch which tries to
>>>>> insert a dependency here.  I find your reasoning to be wrong, and
>>>>> sufficiently short sighted and detrimental to users, that I'm not going
>>>>> to let the patch in.
>>>> Since iirc you didn't respond to my most recent comment on v1 here,
>>>> I would have very much hoped you'd explain your position a little
>>>> better than just claiming that the symbol becoming invisible with a
>>>> dependency added is a bad thing. I'm certainly open to (good)
>>>> arguments, but I'm not accepting a plain statement without proper
>>>> explanation.
>>> I'm not sure how to put this any more clearly.
>>>
>>> Our users cannot read *your* mind when they are trying to use `make
>>> menuconfig`.
>>>
>>> Since our users are not experts in Xen, the lack of an HVM option is
>>> going to cause confusion and questions to mailing lists/IRC, rather than
>>> the realisation that (obviously?) they needed to disable
>>> PV_SHIM_EXCLUSIVE first.
>> But that's an argument to remove support for "depends on" altogether
>> from the kconfig sources.
> 
> Nonsense.  That is not a remotely plausible interpretation of what I said.
> 
> Dependences are normal and expected for functionality built on top of
> each other.  What makes this easy and logical for people to navigate is
> that dependencies are normally a self-contained directed acyclic tree.
> 
> In this case, you're adding a link between a leaf at the bottom of the
> PV tree which chops off the entire HVM tree, and it is dependences like
> this which are confusing for users (who are not experts) to navigate.
> 
> If something is going to malfunction (fail to compile/crash on boot/etc)
> then a dependency is the correct tool to use.  Having a slightly fat
> binary with some unused code is not the same class of problem, and
> should not be treated as if they are the same.

And you are willing to exclude that no issues will slip in over time,
where shim-exclusive is taken to imply absence of HVM support?
A pretty obvious example could be the simple omission of an
is_{pv,hvm}_...() check somewhere.

>>> Finally (and minor in comparison), from the point of view of keeping our
>>> interfaces clean, we'll want Randconfig to occasionally test with both
>>> of them enabled.
>> Why, when the combination doesn't make sense?
> 
> Case in point, "x86: use VMLOAD for PV context switch".
> 
> A user wanting to run PVShim most efficiently on an AMD Fam17h (which
> has virtual vmload/save support) would enable nested virt and want to
> use vmload support.  Such a user would want both
> CONFIG_PV_SHIM_EXCLUSIVE and CONFIG_HVM enabled.

I doubt this is a suitable example. I have a hard time seeing anyone
wanting to pull in the whole HVM baggage just for this one piece of
optimization.

>> Anyway - I'm extending the Cc list to get the more general underlying
>> question resolved. To those who haven't followed the discussion from
>> the beginning: The question is whether senseless combinations of
>> Kconfig options should be permitted, or whether instead "depends on"
>> is a reasonable thing to use in such cases to prevent their (combined)
>> selection.
> 
> The people whose opinions matter most here are those who build/package
> Xen, who are not developers and therefore not experts in how the
> hypervisor fits together.
> 
> If it turns out that the majority of users disagree with me, then I'll
> withdraw my nack, but the reason I'm being such a pain in this regard is
> that this thread re-enforces my opinion that your judgement here is
> wrong, is actively detrimental to usability (which is far wider than
> just developer usability), and that the users will agree with me in this
> matter.

That's as much your anticipation of what they might want, as it is
mine to think that helping them to avoid bogus configurations is the
best we can do here.

Jan


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