While we want certain things turned off in shim-exclusive mode, doing
so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
a result. Yet allyesconfig wants to enable as much of the functionality
as possible.

Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
C code using it can remain as is. This isn't just for less code churn,
but also because I think that symbol is more logical to use in many
(all?) places.

Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
The new Kconfig control's name is up for improvement suggestions, but I
think it's already better than the originally thought of
FULL_HYPERVISOR.

Secondary Kconfig changes could be omitted; in all of the cases I wasn't
really sure whether do the adjustments. I think to avoid setting a bad
precedent we want to avoid "depends on !..." (and hence also the
functionally equivalent "if !..."), but any default settings or prompt
controls could also be left as they were (or could be done the other way
around in subsequent patches).

The Requested-by: isn't for what exactly is done here, but for the
underlying principle of avoiding the negative dependencies we've grown.

Outside of Arm-specific code we have two more negative "depends on":
COVERAGE requires !LIVEPATCH and SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
requires !ENFORCE_UNIQUE_SYMBOLS. The latter could apparently be
switched to a choice (enforce, warn, don't warn), but then I'm not sure
how well choices play with allyesconfig (I guess the default setting is
used).
---
v2: New.

--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -103,7 +103,7 @@ config PV_LINEAR_PT
 
 config HVM
 	bool "HVM support"
-	depends on !PV_SHIM_EXCLUSIVE
+	depends on UNCONSTRAINED
 	default !PV_SHIM
 	select COMPAT
 	select IOREQ_SERVER
@@ -145,7 +145,7 @@ config XEN_IBT
 
 config SHADOW_PAGING
 	bool "Shadow Paging"
-	default !PV_SHIM_EXCLUSIVE
+	default UNCONSTRAINED
 	depends on PV || HVM
 	---help---
 
@@ -196,7 +196,7 @@ config HVM_FEP
 config TBOOT
 	bool "Xen tboot support (UNSUPPORTED)"
 	depends on UNSUPPORTED
-	default !PV_SHIM_EXCLUSIVE
+	default UNCONSTRAINED
 	select CRYPTO
 	---help---
 	  Allows support for Trusted Boot using the Intel(R) Trusted Execution
@@ -276,17 +276,19 @@ config PV_SHIM
 
 	  If unsure, say Y.
 
-config PV_SHIM_EXCLUSIVE
-	bool "PV Shim Exclusive"
-	depends on PV_SHIM
-	---help---
-	  Build Xen in a way which unconditionally assumes PV_SHIM mode.  This
-	  option is only intended for use when building a dedicated PV Shim
-	  firmware, and will not function correctly in other scenarios.
+config UNCONSTRAINED
+	bool "do NOT build a functionality restricted hypervisor" if PV_SHIM
+	default y
+	help
+	  Do NOT build Xen in a way which unconditionally assumes PV_SHIM mode.
 
-	  If unsure, say N.
+	  If unsure, say Y.
+
+config PV_SHIM_EXCLUSIVE
+	def_bool y
+	depends on !UNCONSTRAINED
 
-if !PV_SHIM_EXCLUSIVE
+if UNCONSTRAINED
 
 config HYPERV_GUEST
 	bool "Hyper-V Guest"
--- a/xen/arch/x86/configs/pvshim_defconfig
+++ b/xen/arch/x86/configs/pvshim_defconfig
@@ -3,7 +3,7 @@ CONFIG_PV=y
 CONFIG_XEN_GUEST=y
 CONFIG_PVH_GUEST=y
 CONFIG_PV_SHIM=y
-CONFIG_PV_SHIM_EXCLUSIVE=y
+# CONFIG_UNCONSTRAINED is not set
 CONFIG_NR_CPUS=32
 CONFIG_EXPERT=y
 # Disable features not used by the PV shim
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -3,10 +3,10 @@ config VIDEO
 	bool
 
 config VGA
-	bool "VGA support" if !PV_SHIM_EXCLUSIVE
+	bool "VGA support" if UNCONSTRAINED
 	select VIDEO
 	depends on X86
-	default y if !PV_SHIM_EXCLUSIVE
+	default y if UNCONSTRAINED
 	---help---
 	  Enable VGA output for the Xen hypervisor.

On Wed, 1 Mar 2023, Jan Beulich wrote:
> While we want certain things turned off in shim-exclusive mode, doing
> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> a result. Yet allyesconfig wants to enable as much of the functionality
> as possible.
> 
> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> C code using it can remain as is. This isn't just for less code churn,
> but also because I think that symbol is more logical to use in many
> (all?) places.
> 
> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> ---
> The new Kconfig control's name is up for improvement suggestions, but I
> think it's already better than the originally thought of
> FULL_HYPERVISOR.

I think the approach in general is OK, maybe we can improve the naming
further. What about one of the following?

NO_PV_SHIM_EXCLUSIVE
PV_SHIM_NOT_EXCLUSIVE
ADD_PV_SHIM
PV_SHIM_AND_HYPERVISOR

This is because I think the option should be tied to PV_SHIM. Keep in
mind that users are supposed to be able to use "make menuconfig" and
pick good options based on the menu. An option called UNCONSTRAINED or
FULL_HYPERVISOR or any other name that has nothing to do with PV_SHIM is
very confusing to me.


> Secondary Kconfig changes could be omitted; in all of the cases I wasn't
> really sure whether do the adjustments. I think to avoid setting a bad
> precedent we want to avoid "depends on !..." (and hence also the
> functionally equivalent "if !..."), but any default settings or prompt
> controls could also be left as they were (or could be done the other way
> around in subsequent patches).
> 
> The Requested-by: isn't for what exactly is done here, but for the
> underlying principle of avoiding the negative dependencies we've grown.
> 
> Outside of Arm-specific code we have two more negative "depends on":
> COVERAGE requires !LIVEPATCH and SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
> requires !ENFORCE_UNIQUE_SYMBOLS. The latter could apparently be
> switched to a choice (enforce, warn, don't warn), but then I'm not sure
> how well choices play with allyesconfig (I guess the default setting is
> used).
> ---
> v2: New.
> 
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -103,7 +103,7 @@ config PV_LINEAR_PT
>  
>  config HVM
>  	bool "HVM support"
> -	depends on !PV_SHIM_EXCLUSIVE
> +	depends on UNCONSTRAINED
>  	default !PV_SHIM
>  	select COMPAT
>  	select IOREQ_SERVER
> @@ -145,7 +145,7 @@ config XEN_IBT
>  
>  config SHADOW_PAGING
>  	bool "Shadow Paging"
> -	default !PV_SHIM_EXCLUSIVE
> +	default UNCONSTRAINED
>  	depends on PV || HVM
>  	---help---
>  
> @@ -196,7 +196,7 @@ config HVM_FEP
>  config TBOOT
>  	bool "Xen tboot support (UNSUPPORTED)"
>  	depends on UNSUPPORTED
> -	default !PV_SHIM_EXCLUSIVE
> +	default UNCONSTRAINED
>  	select CRYPTO
>  	---help---
>  	  Allows support for Trusted Boot using the Intel(R) Trusted Execution
> @@ -276,17 +276,19 @@ config PV_SHIM
>  
>  	  If unsure, say Y.
>  
> -config PV_SHIM_EXCLUSIVE
> -	bool "PV Shim Exclusive"
> -	depends on PV_SHIM
> -	---help---
> -	  Build Xen in a way which unconditionally assumes PV_SHIM mode.  This
> -	  option is only intended for use when building a dedicated PV Shim
> -	  firmware, and will not function correctly in other scenarios.
> +config UNCONSTRAINED
> +	bool "do NOT build a functionality restricted hypervisor" if PV_SHIM
> +	default y
> +	help
> +	  Do NOT build Xen in a way which unconditionally assumes PV_SHIM mode.
>  
> -	  If unsure, say N.
> +	  If unsure, say Y.

Yes, the option should not be visible and default y unless PV_SHIM is
selected, like you did.

I think this patch is fine overall, I only suggest a renaming of
UNCONSTRAINED to something to ties it to PV_SHIM.


> +config PV_SHIM_EXCLUSIVE
> +	def_bool y
> +	depends on !UNCONSTRAINED
>  
> -if !PV_SHIM_EXCLUSIVE
> +if UNCONSTRAINED
>  
>  config HYPERV_GUEST
>  	bool "Hyper-V Guest"
> --- a/xen/arch/x86/configs/pvshim_defconfig
> +++ b/xen/arch/x86/configs/pvshim_defconfig
> @@ -3,7 +3,7 @@ CONFIG_PV=y
>  CONFIG_XEN_GUEST=y
>  CONFIG_PVH_GUEST=y
>  CONFIG_PV_SHIM=y
> -CONFIG_PV_SHIM_EXCLUSIVE=y
> +# CONFIG_UNCONSTRAINED is not set
>  CONFIG_NR_CPUS=32
>  CONFIG_EXPERT=y
>  # Disable features not used by the PV shim
> --- a/xen/drivers/video/Kconfig
> +++ b/xen/drivers/video/Kconfig
> @@ -3,10 +3,10 @@ config VIDEO
>  	bool
>  
>  config VGA
> -	bool "VGA support" if !PV_SHIM_EXCLUSIVE
> +	bool "VGA support" if UNCONSTRAINED
>  	select VIDEO
>  	depends on X86
> -	default y if !PV_SHIM_EXCLUSIVE
> +	default y if UNCONSTRAINED
>  	---help---
>  	  Enable VGA output for the Xen hypervisor.
>  
> 
>

On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> On Wed, 1 Mar 2023, Jan Beulich wrote:
> > While we want certain things turned off in shim-exclusive mode, doing
> > so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> > that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> > a result. Yet allyesconfig wants to enable as much of the functionality
> > as possible.
> > 
> > Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> > C code using it can remain as is. This isn't just for less code churn,
> > but also because I think that symbol is more logical to use in many
> > (all?) places.
> > 
> > Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >
> > ---
> > The new Kconfig control's name is up for improvement suggestions, but I
> > think it's already better than the originally thought of
> > FULL_HYPERVISOR.
> 
> I think the approach in general is OK, maybe we can improve the naming
> further. What about one of the following?
> 
> NO_PV_SHIM_EXCLUSIVE
> PV_SHIM_NOT_EXCLUSIVE

IMO negated options are confusing, and if possible I think we should
avoid using them unless strictly necessary.

I for example always considered extremely confusing that previous to
having CONFIG_DEBUG Xen used NDEBUG (so no debug) as a way to signal
debug vs non-debug builds.

Thanks, Roger.

On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> > On Wed, 1 Mar 2023, Jan Beulich wrote:
> > > While we want certain things turned off in shim-exclusive mode, doing
> > > so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> > > that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> > > a result. Yet allyesconfig wants to enable as much of the functionality
> > > as possible.
> > > 
> > > Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> > > C code using it can remain as is. This isn't just for less code churn,
> > > but also because I think that symbol is more logical to use in many
> > > (all?) places.
> > > 
> > > Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > >
> > > ---
> > > The new Kconfig control's name is up for improvement suggestions, but I
> > > think it's already better than the originally thought of
> > > FULL_HYPERVISOR.
> > 
> > I think the approach in general is OK, maybe we can improve the naming
> > further. What about one of the following?
> > 
> > NO_PV_SHIM_EXCLUSIVE
> > PV_SHIM_NOT_EXCLUSIVE
>
> IMO negated options are confusing, and if possible I think we should
> avoid using them unless strictly necessary.

The problem is that the option is negative in nature. It's asking for
hypervisor without _something_. I do agree with Stefano that shim would be
better in the name. Otherwise readers are forced to play divination tricks.

How about something like:

    SHIMLESS_HYPERVISOR

That's arguably not negated, preserves "shim" in the name and has the correct
polarity for allyesconfig to yield the right thing.

>
> I for example always considered extremely confusing that previous to
> having CONFIG_DEBUG Xen used NDEBUG (so no debug) as a way to signal
> debug vs non-debug builds.
>
> Thanks, Roger.

Cheers,
Alejandro

On 17.01.2025 13:24, Alejandro Vallejo wrote:
> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
>>>> While we want certain things turned off in shim-exclusive mode, doing
>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>>>> a result. Yet allyesconfig wants to enable as much of the functionality
>>>> as possible.
>>>>
>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>>>> C code using it can remain as is. This isn't just for less code churn,
>>>> but also because I think that symbol is more logical to use in many
>>>> (all?) places.
>>>>
>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>
>>>> ---
>>>> The new Kconfig control's name is up for improvement suggestions, but I
>>>> think it's already better than the originally thought of
>>>> FULL_HYPERVISOR.
>>>
>>> I think the approach in general is OK, maybe we can improve the naming
>>> further. What about one of the following?
>>>
>>> NO_PV_SHIM_EXCLUSIVE
>>> PV_SHIM_NOT_EXCLUSIVE
>>
>> IMO negated options are confusing, and if possible I think we should
>> avoid using them unless strictly necessary.
> 
> The problem is that the option is negative in nature. It's asking for
> hypervisor without _something_. I do agree with Stefano that shim would be
> better in the name. Otherwise readers are forced to play divination tricks.
> 
> How about something like:
> 
>     SHIMLESS_HYPERVISOR
> 
> That's arguably not negated, preserves "shim" in the name and has the correct
> polarity for allyesconfig to yield the right thing.

Except that a hypervisor with this option enabled isn't shim-less, but permits
working in shim as well as in non-shim mode.

Jan

On Fri, 17 Jan 2025, Jan Beulich wrote:
> On 17.01.2025 13:24, Alejandro Vallejo wrote:
> > On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
> >> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> >>> On Wed, 1 Mar 2023, Jan Beulich wrote:
> >>>> While we want certain things turned off in shim-exclusive mode, doing
> >>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> >>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> >>>> a result. Yet allyesconfig wants to enable as much of the functionality
> >>>> as possible.
> >>>>
> >>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> >>>> C code using it can remain as is. This isn't just for less code churn,
> >>>> but also because I think that symbol is more logical to use in many
> >>>> (all?) places.
> >>>>
> >>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>>
> >>>> ---
> >>>> The new Kconfig control's name is up for improvement suggestions, but I
> >>>> think it's already better than the originally thought of
> >>>> FULL_HYPERVISOR.
> >>>
> >>> I think the approach in general is OK, maybe we can improve the naming
> >>> further. What about one of the following?
> >>>
> >>> NO_PV_SHIM_EXCLUSIVE
> >>> PV_SHIM_NOT_EXCLUSIVE
> >>
> >> IMO negated options are confusing, and if possible I think we should
> >> avoid using them unless strictly necessary.
> > 
> > The problem is that the option is negative in nature. It's asking for
> > hypervisor without _something_. I do agree with Stefano that shim would be
> > better in the name. Otherwise readers are forced to play divination tricks.
> > 
> > How about something like:
> > 
> >     SHIMLESS_HYPERVISOR
> > 
> > That's arguably not negated, preserves "shim" in the name and has the correct
> > polarity for allyesconfig to yield the right thing.
> 
> Except that a hypervisor with this option enabled isn't shim-less, but permits
> working in shim as well as in non-shim mode.

First, let's recognize that we have two opposing requirements. One
requirement is to make it as easy as possible to configure for the user.
Ideally without using negative CONFIG options, such as
NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
I think.

On the other hand, we have the requirement that we don't want
allyesconfig to end up disabling a bunch of CONFIG options. Now this
requirement can be satisfied easily by adding something like
NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
requirement.

So we need a compromise, something that doesn't end up disabling other
CONFIG options, to make allyesconfig happy, but also not too confusing
for the user (which is a matter of personal opinion).

In short, expect that people will have different opinions on this and
will find different compromises better or worse. For one, I prefer to
compromise on "no negative CONFIG options" and use
PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
completely generic FULL_HYPERVISOR option, which means nothing to me.

I cannot see a way to have a good and clear non-negated CONFIG option,
and also satisfy the allyesconfig requirement. So I prefer to compromise
on the "non-negated" part.

On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
> On Fri, 17 Jan 2025, Jan Beulich wrote:
>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
>>>>>> While we want certain things turned off in shim-exclusive mode, doing
>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
>>>>>> as possible.
>>>>>>
>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>>>>>> C code using it can remain as is. This isn't just for less code churn,
>>>>>> but also because I think that symbol is more logical to use in many
>>>>>> (all?) places.
>>>>>>
>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>
>>>>>> ---
>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
>>>>>> think it's already better than the originally thought of
>>>>>> FULL_HYPERVISOR.
>>>>> I think the approach in general is OK, maybe we can improve the naming
>>>>> further. What about one of the following?
>>>>>
>>>>> NO_PV_SHIM_EXCLUSIVE
>>>>> PV_SHIM_NOT_EXCLUSIVE
>>>> IMO negated options are confusing, and if possible I think we should
>>>> avoid using them unless strictly necessary.
>>> The problem is that the option is negative in nature. It's asking for
>>> hypervisor without _something_. I do agree with Stefano that shim would be
>>> better in the name. Otherwise readers are forced to play divination tricks.
>>>
>>> How about something like:
>>>
>>>     SHIMLESS_HYPERVISOR
>>>
>>> That's arguably not negated, preserves "shim" in the name and has the correct
>>> polarity for allyesconfig to yield the right thing.
>> Except that a hypervisor with this option enabled isn't shim-less, but permits
>> working in shim as well as in non-shim mode.
> First, let's recognize that we have two opposing requirements. One
> requirement is to make it as easy as possible to configure for the user.
> Ideally without using negative CONFIG options, such as
> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
> I think.
>
> On the other hand, we have the requirement that we don't want
> allyesconfig to end up disabling a bunch of CONFIG options. Now this
> requirement can be satisfied easily by adding something like
> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
> requirement.
>
> So we need a compromise, something that doesn't end up disabling other
> CONFIG options, to make allyesconfig happy, but also not too confusing
> for the user (which is a matter of personal opinion).
>
> In short, expect that people will have different opinions on this and
> will find different compromises better or worse. For one, I prefer to
> compromise on "no negative CONFIG options" and use
> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
> completely generic FULL_HYPERVISOR option, which means nothing to me.
>
> I cannot see a way to have a good and clear non-negated CONFIG option,
> and also satisfy the allyesconfig requirement. So I prefer to compromise
> on the "non-negated" part.

Debating the naming is missing the point.


The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
that Kconfig is not capable of expressing.  Specifically, what is broken
is having "lower level" options inhibit unrelated "higher level" options
when the graph gets rescanned[1].  That's why we're in the laughable
position of `make allyesconfig` turning off CONFIG_HVM.

Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
"reset me back to a PV Shim".

Kconfig spells this "make $foo_defconfig" for an appropriately given foo.


There should be:

1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
making the boolean be a compile time constant.

2) a pvshim_defconfig target which expresses what a pvshim ought to look
like.

Trying to fight against the behaviour of Kconfig is not a good use of
anyone's time.

~Andrew

[1] default to unrelated symbols is also broken for a related reason. 
The result you get is sensitive to the order of processing of symbols.

On 18.01.2025 00:41, Andrew Cooper wrote:
> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
>> On Fri, 17 Jan 2025, Jan Beulich wrote:
>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
>>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
>>>>>>> While we want certain things turned off in shim-exclusive mode, doing
>>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
>>>>>>> as possible.
>>>>>>>
>>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>>>>>>> C code using it can remain as is. This isn't just for less code churn,
>>>>>>> but also because I think that symbol is more logical to use in many
>>>>>>> (all?) places.
>>>>>>>
>>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>>
>>>>>>> ---
>>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
>>>>>>> think it's already better than the originally thought of
>>>>>>> FULL_HYPERVISOR.
>>>>>> I think the approach in general is OK, maybe we can improve the naming
>>>>>> further. What about one of the following?
>>>>>>
>>>>>> NO_PV_SHIM_EXCLUSIVE
>>>>>> PV_SHIM_NOT_EXCLUSIVE
>>>>> IMO negated options are confusing, and if possible I think we should
>>>>> avoid using them unless strictly necessary.
>>>> The problem is that the option is negative in nature. It's asking for
>>>> hypervisor without _something_. I do agree with Stefano that shim would be
>>>> better in the name. Otherwise readers are forced to play divination tricks.
>>>>
>>>> How about something like:
>>>>
>>>>     SHIMLESS_HYPERVISOR
>>>>
>>>> That's arguably not negated, preserves "shim" in the name and has the correct
>>>> polarity for allyesconfig to yield the right thing.
>>> Except that a hypervisor with this option enabled isn't shim-less, but permits
>>> working in shim as well as in non-shim mode.
>> First, let's recognize that we have two opposing requirements. One
>> requirement is to make it as easy as possible to configure for the user.
>> Ideally without using negative CONFIG options, such as
>> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
>> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
>> I think.
>>
>> On the other hand, we have the requirement that we don't want
>> allyesconfig to end up disabling a bunch of CONFIG options. Now this
>> requirement can be satisfied easily by adding something like
>> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
>> requirement.
>>
>> So we need a compromise, something that doesn't end up disabling other
>> CONFIG options, to make allyesconfig happy, but also not too confusing
>> for the user (which is a matter of personal opinion).
>>
>> In short, expect that people will have different opinions on this and
>> will find different compromises better or worse. For one, I prefer to
>> compromise on "no negative CONFIG options" and use
>> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
>> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
>> completely generic FULL_HYPERVISOR option, which means nothing to me.
>>
>> I cannot see a way to have a good and clear non-negated CONFIG option,
>> and also satisfy the allyesconfig requirement. So I prefer to compromise
>> on the "non-negated" part.
> 
> Debating the naming is missing the point.
> 
> 
> The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
> that Kconfig is not capable of expressing.  Specifically, what is broken
> is having "lower level" options inhibit unrelated "higher level" options
> when the graph gets rescanned[1].  That's why we're in the laughable
> position of `make allyesconfig` turning off CONFIG_HVM.
> 
> Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
> "reset me back to a PV Shim".

Isn't this an independent goal? Or is this a statement on what you see
my change (kind of) doing, indicating you consider this wrong?

> Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
> 
> 
> There should be:
> 
> 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
> making the boolean be a compile time constant.

I fear it remains unclear to me what exactly you mean here. It feels like
you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
dropped, without replacement. That seems wrong to me, though. In
particular I'm of the opinion that besides using "make pvshim_defconfig"
people ought to also have the option to properly configure a shim build
from scratch (or from any random .config they hold in hands), requiring
respective "depends on" and/or "select" / "imply" to be in place. Or else
they may end up with a lot of dead code. (Just consider e.g. HVM=n: We
also don't permit HVM-only stuff to be enabled in that case, as any of
that would again be dead code then.)

> 2) a pvshim_defconfig target which expresses what a pvshim ought to look
> like.

We have this file already. I consider it debatable though whether this file
should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
name as either "works just as shim" or "can also work as shim".

> Trying to fight against the behaviour of Kconfig is not a good use of
> anyone's time.
> 
> ~Andrew
> 
> [1] default to unrelated symbols is also broken for a related reason. 
> The result you get is sensitive to the order of processing of symbols.

Is it? It has been my understanding that defaults get re-evaluated as user
input is processed.

Jan

On Mon, 20 Jan 2025, Jan Beulich wrote:
> On 18.01.2025 00:41, Andrew Cooper wrote:
> > On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
> >> On Fri, 17 Jan 2025, Jan Beulich wrote:
> >>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
> >>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
> >>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> >>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
> >>>>>>> While we want certain things turned off in shim-exclusive mode, doing
> >>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> >>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> >>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
> >>>>>>> as possible.
> >>>>>>>
> >>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> >>>>>>> C code using it can remain as is. This isn't just for less code churn,
> >>>>>>> but also because I think that symbol is more logical to use in many
> >>>>>>> (all?) places.
> >>>>>>>
> >>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>>>>>
> >>>>>>> ---
> >>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
> >>>>>>> think it's already better than the originally thought of
> >>>>>>> FULL_HYPERVISOR.
> >>>>>> I think the approach in general is OK, maybe we can improve the naming
> >>>>>> further. What about one of the following?
> >>>>>>
> >>>>>> NO_PV_SHIM_EXCLUSIVE
> >>>>>> PV_SHIM_NOT_EXCLUSIVE
> >>>>> IMO negated options are confusing, and if possible I think we should
> >>>>> avoid using them unless strictly necessary.
> >>>> The problem is that the option is negative in nature. It's asking for
> >>>> hypervisor without _something_. I do agree with Stefano that shim would be
> >>>> better in the name. Otherwise readers are forced to play divination tricks.
> >>>>
> >>>> How about something like:
> >>>>
> >>>>     SHIMLESS_HYPERVISOR
> >>>>
> >>>> That's arguably not negated, preserves "shim" in the name and has the correct
> >>>> polarity for allyesconfig to yield the right thing.
> >>> Except that a hypervisor with this option enabled isn't shim-less, but permits
> >>> working in shim as well as in non-shim mode.
> >> First, let's recognize that we have two opposing requirements. One
> >> requirement is to make it as easy as possible to configure for the user.
> >> Ideally without using negative CONFIG options, such as
> >> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
> >> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
> >> I think.
> >>
> >> On the other hand, we have the requirement that we don't want
> >> allyesconfig to end up disabling a bunch of CONFIG options. Now this
> >> requirement can be satisfied easily by adding something like
> >> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
> >> requirement.
> >>
> >> So we need a compromise, something that doesn't end up disabling other
> >> CONFIG options, to make allyesconfig happy, but also not too confusing
> >> for the user (which is a matter of personal opinion).
> >>
> >> In short, expect that people will have different opinions on this and
> >> will find different compromises better or worse. For one, I prefer to
> >> compromise on "no negative CONFIG options" and use
> >> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
> >> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
> >> completely generic FULL_HYPERVISOR option, which means nothing to me.
> >>
> >> I cannot see a way to have a good and clear non-negated CONFIG option,
> >> and also satisfy the allyesconfig requirement. So I prefer to compromise
> >> on the "non-negated" part.
> > 
> > Debating the naming is missing the point.
> > 
> > 
> > The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
> > that Kconfig is not capable of expressing.  Specifically, what is broken
> > is having "lower level" options inhibit unrelated "higher level" options
> > when the graph gets rescanned[1].  That's why we're in the laughable
> > position of `make allyesconfig` turning off CONFIG_HVM.
> > 
> > Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
> > "reset me back to a PV Shim".
> 
> Isn't this an independent goal? Or is this a statement on what you see
> my change (kind of) doing, indicating you consider this wrong?

The way I understood it, it is the latter


> > Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
> > 
> > 
> > There should be:
> > 
> > 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
> > making the boolean be a compile time constant.
> 
> I fear it remains unclear to me what exactly you mean here. It feels like
> you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
> dropped, without replacement. That seems wrong to me, though. In
> particular I'm of the opinion that besides using "make pvshim_defconfig"
> people ought to also have the option to properly configure a shim build
> from scratch (or from any random .config they hold in hands), requiring
> respective "depends on" and/or "select" / "imply" to be in place.

That should be done with "make pvshim_defconfig"


> Or else they may end up with a lot of dead code. (Just consider e.g.
> HVM=n: We also don't permit HVM-only stuff to be enabled in that case,
> as any of that would again be dead code then.)

It will always be possible to come up with poor configurations. I do not
believe it is necessarily our responsibility to go out of our way to
prevent them.


> > 2) a pvshim_defconfig target which expresses what a pvshim ought to look
> > like.
> 
> We have this file already. I consider it debatable though whether this file
> should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
> name as either "works just as shim" or "can also work as shim".

If I understood it right, I like Andrew's suggestion. He is suggesting
to do the following:

- turning PV_SHIM_EXCLUSIVE into something that does nothing
- adding "make pvshim_defconfig"

So that:

- people use "make pvshim_defconfig" to get what today is enabled by
  PV_SHIM_EXCLUSIVE
- but "make allyesconfig" doesn't end up disabling things
- the Kconfig menu makes sense because PV_SHIM_EXCLUSIVE goes away and
  it is not replaced by anything

If I got it right, I am in favor.

On 21.01.2025 00:27, Stefano Stabellini wrote:
> On Mon, 20 Jan 2025, Jan Beulich wrote:
>> On 18.01.2025 00:41, Andrew Cooper wrote:
>>> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
>>>> On Fri, 17 Jan 2025, Jan Beulich wrote:
>>>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
>>>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
>>>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
>>>>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
>>>>>>>>> While we want certain things turned off in shim-exclusive mode, doing
>>>>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>>>>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>>>>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
>>>>>>>>> as possible.
>>>>>>>>>
>>>>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>>>>>>>>> C code using it can remain as is. This isn't just for less code churn,
>>>>>>>>> but also because I think that symbol is more logical to use in many
>>>>>>>>> (all?) places.
>>>>>>>>>
>>>>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
>>>>>>>>> think it's already better than the originally thought of
>>>>>>>>> FULL_HYPERVISOR.
>>>>>>>> I think the approach in general is OK, maybe we can improve the naming
>>>>>>>> further. What about one of the following?
>>>>>>>>
>>>>>>>> NO_PV_SHIM_EXCLUSIVE
>>>>>>>> PV_SHIM_NOT_EXCLUSIVE
>>>>>>> IMO negated options are confusing, and if possible I think we should
>>>>>>> avoid using them unless strictly necessary.
>>>>>> The problem is that the option is negative in nature. It's asking for
>>>>>> hypervisor without _something_. I do agree with Stefano that shim would be
>>>>>> better in the name. Otherwise readers are forced to play divination tricks.
>>>>>>
>>>>>> How about something like:
>>>>>>
>>>>>>     SHIMLESS_HYPERVISOR
>>>>>>
>>>>>> That's arguably not negated, preserves "shim" in the name and has the correct
>>>>>> polarity for allyesconfig to yield the right thing.
>>>>> Except that a hypervisor with this option enabled isn't shim-less, but permits
>>>>> working in shim as well as in non-shim mode.
>>>> First, let's recognize that we have two opposing requirements. One
>>>> requirement is to make it as easy as possible to configure for the user.
>>>> Ideally without using negative CONFIG options, such as
>>>> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
>>>> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
>>>> I think.
>>>>
>>>> On the other hand, we have the requirement that we don't want
>>>> allyesconfig to end up disabling a bunch of CONFIG options. Now this
>>>> requirement can be satisfied easily by adding something like
>>>> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
>>>> requirement.
>>>>
>>>> So we need a compromise, something that doesn't end up disabling other
>>>> CONFIG options, to make allyesconfig happy, but also not too confusing
>>>> for the user (which is a matter of personal opinion).
>>>>
>>>> In short, expect that people will have different opinions on this and
>>>> will find different compromises better or worse. For one, I prefer to
>>>> compromise on "no negative CONFIG options" and use
>>>> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
>>>> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
>>>> completely generic FULL_HYPERVISOR option, which means nothing to me.
>>>>
>>>> I cannot see a way to have a good and clear non-negated CONFIG option,
>>>> and also satisfy the allyesconfig requirement. So I prefer to compromise
>>>> on the "non-negated" part.
>>>
>>> Debating the naming is missing the point.
>>>
>>>
>>> The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
>>> that Kconfig is not capable of expressing.  Specifically, what is broken
>>> is having "lower level" options inhibit unrelated "higher level" options
>>> when the graph gets rescanned[1].  That's why we're in the laughable
>>> position of `make allyesconfig` turning off CONFIG_HVM.
>>>
>>> Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
>>> "reset me back to a PV Shim".
>>
>> Isn't this an independent goal? Or is this a statement on what you see
>> my change (kind of) doing, indicating you consider this wrong?
> 
> The way I understood it, it is the latter
> 
> 
>>> Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
>>>
>>>
>>> There should be:
>>>
>>> 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
>>> making the boolean be a compile time constant.
>>
>> I fear it remains unclear to me what exactly you mean here. It feels like
>> you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
>> dropped, without replacement. That seems wrong to me, though. In
>> particular I'm of the opinion that besides using "make pvshim_defconfig"
>> people ought to also have the option to properly configure a shim build
>> from scratch (or from any random .config they hold in hands), requiring
>> respective "depends on" and/or "select" / "imply" to be in place.
> 
> That should be done with "make pvshim_defconfig"

Why? Specifically, why should people use only one entirely nailed down
configuration for a shim. Like a "normal" hypervisor, there are aspects
which very well can be left to the person doing the configuration.

>> Or else they may end up with a lot of dead code. (Just consider e.g.
>> HVM=n: We also don't permit HVM-only stuff to be enabled in that case,
>> as any of that would again be dead code then.)
> 
> It will always be possible to come up with poor configurations. I do not
> believe it is necessarily our responsibility to go out of our way to
> prevent them.

Well - if so, why would we do this in some cases but not in others?
You may recall that I'm a proponent of consistency and predictability.

>>> 2) a pvshim_defconfig target which expresses what a pvshim ought to look
>>> like.
>>
>> We have this file already. I consider it debatable though whether this file
>> should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
>> name as either "works just as shim" or "can also work as shim".
> 
> If I understood it right, I like Andrew's suggestion. He is suggesting
> to do the following:
> 
> - turning PV_SHIM_EXCLUSIVE into something that does nothing

FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
"nothing other than making the boolean be a compile time constant".

> - adding "make pvshim_defconfig"

Why do you say "adding"? We have this already.

Jan

> So that:
> 
> - people use "make pvshim_defconfig" to get what today is enabled by
>   PV_SHIM_EXCLUSIVE
> - but "make allyesconfig" doesn't end up disabling things
> - the Kconfig menu makes sense because PV_SHIM_EXCLUSIVE goes away and
>   it is not replaced by anything
> 
> If I got it right, I am in favor.

On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> On 21.01.2025 00:27, Stefano Stabellini wrote:
> > On Mon, 20 Jan 2025, Jan Beulich wrote:
> >> On 18.01.2025 00:41, Andrew Cooper wrote:
> >>> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
> >>>> On Fri, 17 Jan 2025, Jan Beulich wrote:
> >>>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
> >>>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
> >>>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> >>>>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
> >>>>>>>>> While we want certain things turned off in shim-exclusive mode, doing
> >>>>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> >>>>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> >>>>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
> >>>>>>>>> as possible.
> >>>>>>>>>
> >>>>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> >>>>>>>>> C code using it can remain as is. This isn't just for less code churn,
> >>>>>>>>> but also because I think that symbol is more logical to use in many
> >>>>>>>>> (all?) places.
> >>>>>>>>>
> >>>>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>>>>>>>
> >>>>>>>>> ---
> >>>>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
> >>>>>>>>> think it's already better than the originally thought of
> >>>>>>>>> FULL_HYPERVISOR.
> >>>>>>>> I think the approach in general is OK, maybe we can improve the naming
> >>>>>>>> further. What about one of the following?
> >>>>>>>>
> >>>>>>>> NO_PV_SHIM_EXCLUSIVE
> >>>>>>>> PV_SHIM_NOT_EXCLUSIVE
> >>>>>>> IMO negated options are confusing, and if possible I think we should
> >>>>>>> avoid using them unless strictly necessary.
> >>>>>> The problem is that the option is negative in nature. It's asking for
> >>>>>> hypervisor without _something_. I do agree with Stefano that shim would be
> >>>>>> better in the name. Otherwise readers are forced to play divination tricks.
> >>>>>>
> >>>>>> How about something like:
> >>>>>>
> >>>>>>     SHIMLESS_HYPERVISOR
> >>>>>>
> >>>>>> That's arguably not negated, preserves "shim" in the name and has the correct
> >>>>>> polarity for allyesconfig to yield the right thing.
> >>>>> Except that a hypervisor with this option enabled isn't shim-less, but permits
> >>>>> working in shim as well as in non-shim mode.
> >>>> First, let's recognize that we have two opposing requirements. One
> >>>> requirement is to make it as easy as possible to configure for the user.
> >>>> Ideally without using negative CONFIG options, such as
> >>>> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
> >>>> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
> >>>> I think.
> >>>>
> >>>> On the other hand, we have the requirement that we don't want
> >>>> allyesconfig to end up disabling a bunch of CONFIG options. Now this
> >>>> requirement can be satisfied easily by adding something like
> >>>> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
> >>>> requirement.
> >>>>
> >>>> So we need a compromise, something that doesn't end up disabling other
> >>>> CONFIG options, to make allyesconfig happy, but also not too confusing
> >>>> for the user (which is a matter of personal opinion).
> >>>>
> >>>> In short, expect that people will have different opinions on this and
> >>>> will find different compromises better or worse. For one, I prefer to
> >>>> compromise on "no negative CONFIG options" and use
> >>>> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
> >>>> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
> >>>> completely generic FULL_HYPERVISOR option, which means nothing to me.
> >>>>
> >>>> I cannot see a way to have a good and clear non-negated CONFIG option,
> >>>> and also satisfy the allyesconfig requirement. So I prefer to compromise
> >>>> on the "non-negated" part.
> >>>
> >>> Debating the naming is missing the point.
> >>>
> >>>
> >>> The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
> >>> that Kconfig is not capable of expressing.  Specifically, what is broken
> >>> is having "lower level" options inhibit unrelated "higher level" options
> >>> when the graph gets rescanned[1].  That's why we're in the laughable
> >>> position of `make allyesconfig` turning off CONFIG_HVM.
> >>>
> >>> Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
> >>> "reset me back to a PV Shim".
> >>
> >> Isn't this an independent goal? Or is this a statement on what you see
> >> my change (kind of) doing, indicating you consider this wrong?
> > 
> > The way I understood it, it is the latter
> > 
> > 
> >>> Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
> >>>
> >>>
> >>> There should be:
> >>>
> >>> 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
> >>> making the boolean be a compile time constant.
> >>
> >> I fear it remains unclear to me what exactly you mean here. It feels like
> >> you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
> >> dropped, without replacement. That seems wrong to me, though. In
> >> particular I'm of the opinion that besides using "make pvshim_defconfig"
> >> people ought to also have the option to properly configure a shim build
> >> from scratch (or from any random .config they hold in hands), requiring
> >> respective "depends on" and/or "select" / "imply" to be in place.
> > 
> > That should be done with "make pvshim_defconfig"
> 
> Why? Specifically, why should people use only one entirely nailed down
> configuration for a shim. Like a "normal" hypervisor, there are aspects
> which very well can be left to the person doing the configuration.

But nothing prevents a user from starting from a shim defconfig, and
then tweaking it as desired:

$ make pvshim_defconfig
$ make menuconfig

Or there's something I'm missing here?

> >> Or else they may end up with a lot of dead code. (Just consider e.g.
> >> HVM=n: We also don't permit HVM-only stuff to be enabled in that case,
> >> as any of that would again be dead code then.)
> > 
> > It will always be possible to come up with poor configurations. I do not
> > believe it is necessarily our responsibility to go out of our way to
> > prevent them.
> 
> Well - if so, why would we do this in some cases but not in others?
> You may recall that I'm a proponent of consistency and predictability.
> 
> >>> 2) a pvshim_defconfig target which expresses what a pvshim ought to look
> >>> like.
> >>
> >> We have this file already. I consider it debatable though whether this file
> >> should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
> >> name as either "works just as shim" or "can also work as shim".
> > 
> > If I understood it right, I like Andrew's suggestion. He is suggesting
> > to do the following:
> > 
> > - turning PV_SHIM_EXCLUSIVE into something that does nothing
> 
> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
> "nothing other than making the boolean be a compile time constant".

Won't making the boolean a compile time constant would also result in
DCO kicking in and removing a fair amount of code?  So even if you
have enabled everything in Kconfig, the resulting hypervisor would
only be suitable to be used as a shim?

Thanks, Roger.

On 21.01.2025 09:52, Roger Pau Monné wrote:
> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
>> On 21.01.2025 00:27, Stefano Stabellini wrote:
>>> On Mon, 20 Jan 2025, Jan Beulich wrote:
>>>> On 18.01.2025 00:41, Andrew Cooper wrote:
>>>>> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
>>>>>> On Fri, 17 Jan 2025, Jan Beulich wrote:
>>>>>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
>>>>>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
>>>>>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
>>>>>>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
>>>>>>>>>>> While we want certain things turned off in shim-exclusive mode, doing
>>>>>>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>>>>>>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>>>>>>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
>>>>>>>>>>> as possible.
>>>>>>>>>>>
>>>>>>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>>>>>>>>>>> C code using it can remain as is. This isn't just for less code churn,
>>>>>>>>>>> but also because I think that symbol is more logical to use in many
>>>>>>>>>>> (all?) places.
>>>>>>>>>>>
>>>>>>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
>>>>>>>>>>> think it's already better than the originally thought of
>>>>>>>>>>> FULL_HYPERVISOR.
>>>>>>>>>> I think the approach in general is OK, maybe we can improve the naming
>>>>>>>>>> further. What about one of the following?
>>>>>>>>>>
>>>>>>>>>> NO_PV_SHIM_EXCLUSIVE
>>>>>>>>>> PV_SHIM_NOT_EXCLUSIVE
>>>>>>>>> IMO negated options are confusing, and if possible I think we should
>>>>>>>>> avoid using them unless strictly necessary.
>>>>>>>> The problem is that the option is negative in nature. It's asking for
>>>>>>>> hypervisor without _something_. I do agree with Stefano that shim would be
>>>>>>>> better in the name. Otherwise readers are forced to play divination tricks.
>>>>>>>>
>>>>>>>> How about something like:
>>>>>>>>
>>>>>>>>     SHIMLESS_HYPERVISOR
>>>>>>>>
>>>>>>>> That's arguably not negated, preserves "shim" in the name and has the correct
>>>>>>>> polarity for allyesconfig to yield the right thing.
>>>>>>> Except that a hypervisor with this option enabled isn't shim-less, but permits
>>>>>>> working in shim as well as in non-shim mode.
>>>>>> First, let's recognize that we have two opposing requirements. One
>>>>>> requirement is to make it as easy as possible to configure for the user.
>>>>>> Ideally without using negative CONFIG options, such as
>>>>>> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
>>>>>> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
>>>>>> I think.
>>>>>>
>>>>>> On the other hand, we have the requirement that we don't want
>>>>>> allyesconfig to end up disabling a bunch of CONFIG options. Now this
>>>>>> requirement can be satisfied easily by adding something like
>>>>>> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
>>>>>> requirement.
>>>>>>
>>>>>> So we need a compromise, something that doesn't end up disabling other
>>>>>> CONFIG options, to make allyesconfig happy, but also not too confusing
>>>>>> for the user (which is a matter of personal opinion).
>>>>>>
>>>>>> In short, expect that people will have different opinions on this and
>>>>>> will find different compromises better or worse. For one, I prefer to
>>>>>> compromise on "no negative CONFIG options" and use
>>>>>> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
>>>>>> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
>>>>>> completely generic FULL_HYPERVISOR option, which means nothing to me.
>>>>>>
>>>>>> I cannot see a way to have a good and clear non-negated CONFIG option,
>>>>>> and also satisfy the allyesconfig requirement. So I prefer to compromise
>>>>>> on the "non-negated" part.
>>>>>
>>>>> Debating the naming is missing the point.
>>>>>
>>>>>
>>>>> The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
>>>>> that Kconfig is not capable of expressing.  Specifically, what is broken
>>>>> is having "lower level" options inhibit unrelated "higher level" options
>>>>> when the graph gets rescanned[1].  That's why we're in the laughable
>>>>> position of `make allyesconfig` turning off CONFIG_HVM.
>>>>>
>>>>> Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
>>>>> "reset me back to a PV Shim".
>>>>
>>>> Isn't this an independent goal? Or is this a statement on what you see
>>>> my change (kind of) doing, indicating you consider this wrong?
>>>
>>> The way I understood it, it is the latter
>>>
>>>
>>>>> Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
>>>>>
>>>>>
>>>>> There should be:
>>>>>
>>>>> 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
>>>>> making the boolean be a compile time constant.
>>>>
>>>> I fear it remains unclear to me what exactly you mean here. It feels like
>>>> you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
>>>> dropped, without replacement. That seems wrong to me, though. In
>>>> particular I'm of the opinion that besides using "make pvshim_defconfig"
>>>> people ought to also have the option to properly configure a shim build
>>>> from scratch (or from any random .config they hold in hands), requiring
>>>> respective "depends on" and/or "select" / "imply" to be in place.
>>>
>>> That should be done with "make pvshim_defconfig"
>>
>> Why? Specifically, why should people use only one entirely nailed down
>> configuration for a shim. Like a "normal" hypervisor, there are aspects
>> which very well can be left to the person doing the configuration.
> 
> But nothing prevents a user from starting from a shim defconfig, and
> then tweaking it as desired:
> 
> $ make pvshim_defconfig
> $ make menuconfig
> 
> Or there's something I'm missing here?

Well, no, you don't. But if the above is okay, why would not starting from
pvshim_defconfig not also be okay? Plus whichever way tweaks are done,
sensible dependencies should still be enforced imo.

>>>> Or else they may end up with a lot of dead code. (Just consider e.g.
>>>> HVM=n: We also don't permit HVM-only stuff to be enabled in that case,
>>>> as any of that would again be dead code then.)
>>>
>>> It will always be possible to come up with poor configurations. I do not
>>> believe it is necessarily our responsibility to go out of our way to
>>> prevent them.
>>
>> Well - if so, why would we do this in some cases but not in others?
>> You may recall that I'm a proponent of consistency and predictability.
>>
>>>>> 2) a pvshim_defconfig target which expresses what a pvshim ought to look
>>>>> like.
>>>>
>>>> We have this file already. I consider it debatable though whether this file
>>>> should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
>>>> name as either "works just as shim" or "can also work as shim".
>>>
>>> If I understood it right, I like Andrew's suggestion. He is suggesting
>>> to do the following:
>>>
>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
>>
>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
>> "nothing other than making the boolean be a compile time constant".
> 
> Won't making the boolean a compile time constant would also result in
> DCO kicking in and removing a fair amount of code?  So even if you
> have enabled everything in Kconfig, the resulting hypervisor would
> only be suitable to be used as a shim?

Of course.

Jan

On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
> On 21.01.2025 09:52, Roger Pau Monné wrote:
> > On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> >> On 21.01.2025 00:27, Stefano Stabellini wrote:
> >>> On Mon, 20 Jan 2025, Jan Beulich wrote:
> >>>> On 18.01.2025 00:41, Andrew Cooper wrote:
> >>>>> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
> >>>>>> On Fri, 17 Jan 2025, Jan Beulich wrote:
> >>>>>>> On 17.01.2025 13:24, Alejandro Vallejo wrote:
> >>>>>>>> On Fri Jan 17, 2025 at 10:31 AM GMT, Roger Pau Monné wrote:
> >>>>>>>>> On Thu, Jan 16, 2025 at 04:31:46PM -0800, Stefano Stabellini wrote:
> >>>>>>>>>> On Wed, 1 Mar 2023, Jan Beulich wrote:
> >>>>>>>>>>> While we want certain things turned off in shim-exclusive mode, doing
> >>>>>>>>>>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
> >>>>>>>>>>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
> >>>>>>>>>>> a result. Yet allyesconfig wants to enable as much of the functionality
> >>>>>>>>>>> as possible.
> >>>>>>>>>>>
> >>>>>>>>>>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
> >>>>>>>>>>> C code using it can remain as is. This isn't just for less code churn,
> >>>>>>>>>>> but also because I think that symbol is more logical to use in many
> >>>>>>>>>>> (all?) places.
> >>>>>>>>>>>
> >>>>>>>>>>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >>>>>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>>>>>>>>>>
> >>>>>>>>>>> ---
> >>>>>>>>>>> The new Kconfig control's name is up for improvement suggestions, but I
> >>>>>>>>>>> think it's already better than the originally thought of
> >>>>>>>>>>> FULL_HYPERVISOR.
> >>>>>>>>>> I think the approach in general is OK, maybe we can improve the naming
> >>>>>>>>>> further. What about one of the following?
> >>>>>>>>>>
> >>>>>>>>>> NO_PV_SHIM_EXCLUSIVE
> >>>>>>>>>> PV_SHIM_NOT_EXCLUSIVE
> >>>>>>>>> IMO negated options are confusing, and if possible I think we should
> >>>>>>>>> avoid using them unless strictly necessary.
> >>>>>>>> The problem is that the option is negative in nature. It's asking for
> >>>>>>>> hypervisor without _something_. I do agree with Stefano that shim would be
> >>>>>>>> better in the name. Otherwise readers are forced to play divination tricks.
> >>>>>>>>
> >>>>>>>> How about something like:
> >>>>>>>>
> >>>>>>>>     SHIMLESS_HYPERVISOR
> >>>>>>>>
> >>>>>>>> That's arguably not negated, preserves "shim" in the name and has the correct
> >>>>>>>> polarity for allyesconfig to yield the right thing.
> >>>>>>> Except that a hypervisor with this option enabled isn't shim-less, but permits
> >>>>>>> working in shim as well as in non-shim mode.
> >>>>>> First, let's recognize that we have two opposing requirements. One
> >>>>>> requirement is to make it as easy as possible to configure for the user.
> >>>>>> Ideally without using negative CONFIG options, such as
> >>>>>> NO_PV_SHIM_EXCLUSIVE. From the user point of view, honestly,
> >>>>>> PV_SHIM_EXCLUSIVE is a pretty good name. Better than all of the others,
> >>>>>> I think.
> >>>>>>
> >>>>>> On the other hand, we have the requirement that we don't want
> >>>>>> allyesconfig to end up disabling a bunch of CONFIG options. Now this
> >>>>>> requirement can be satisfied easily by adding something like
> >>>>>> NO_PV_SHIM_EXCLUSIVE. However, it would go somewhat against the previous
> >>>>>> requirement.
> >>>>>>
> >>>>>> So we need a compromise, something that doesn't end up disabling other
> >>>>>> CONFIG options, to make allyesconfig happy, but also not too confusing
> >>>>>> for the user (which is a matter of personal opinion).
> >>>>>>
> >>>>>> In short, expect that people will have different opinions on this and
> >>>>>> will find different compromises better or worse. For one, I prefer to
> >>>>>> compromise on "no negative CONFIG options" and use
> >>>>>> PV_SHIM_NOT_EXCLUSIVE. Because it serves the allyesconfig goal, and
> >>>>>> while it is not as clear as PV_SHIM_EXCLUSIVE, is still better than a
> >>>>>> completely generic FULL_HYPERVISOR option, which means nothing to me.
> >>>>>>
> >>>>>> I cannot see a way to have a good and clear non-negated CONFIG option,
> >>>>>> and also satisfy the allyesconfig requirement. So I prefer to compromise
> >>>>>> on the "non-negated" part.
> >>>>>
> >>>>> Debating the naming is missing the point.
> >>>>>
> >>>>>
> >>>>> The problem here is the wish to have PV_SHIM_EXCLUSIVE behave in a way
> >>>>> that Kconfig is not capable of expressing.  Specifically, what is broken
> >>>>> is having "lower level" options inhibit unrelated "higher level" options
> >>>>> when the graph gets rescanned[1].  That's why we're in the laughable
> >>>>> position of `make allyesconfig` turning off CONFIG_HVM.
> >>>>>
> >>>>> Jan, you want "echo PV_SHIM_EXCLUSIVE=y >> .config && make" to mean
> >>>>> "reset me back to a PV Shim".
> >>>>
> >>>> Isn't this an independent goal? Or is this a statement on what you see
> >>>> my change (kind of) doing, indicating you consider this wrong?
> >>>
> >>> The way I understood it, it is the latter
> >>>
> >>>
> >>>>> Kconfig spells this "make $foo_defconfig" for an appropriately given foo.
> >>>>>
> >>>>>
> >>>>> There should be:
> >>>>>
> >>>>> 1) an option called PV_SHIM_EXCLUSIVE which does *nothing* other than
> >>>>> making the boolean be a compile time constant.
> >>>>
> >>>> I fear it remains unclear to me what exactly you mean here. It feels like
> >>>> you may be suggesting that all other uses of PV_SHIM_EXCLUSIVE should be
> >>>> dropped, without replacement. That seems wrong to me, though. In
> >>>> particular I'm of the opinion that besides using "make pvshim_defconfig"
> >>>> people ought to also have the option to properly configure a shim build
> >>>> from scratch (or from any random .config they hold in hands), requiring
> >>>> respective "depends on" and/or "select" / "imply" to be in place.
> >>>
> >>> That should be done with "make pvshim_defconfig"
> >>
> >> Why? Specifically, why should people use only one entirely nailed down
> >> configuration for a shim. Like a "normal" hypervisor, there are aspects
> >> which very well can be left to the person doing the configuration.
> > 
> > But nothing prevents a user from starting from a shim defconfig, and
> > then tweaking it as desired:
> > 
> > $ make pvshim_defconfig
> > $ make menuconfig
> > 
> > Or there's something I'm missing here?
> 
> Well, no, you don't. But if the above is okay, why would not starting from
> pvshim_defconfig not also be okay? Plus whichever way tweaks are done,
> sensible dependencies should still be enforced imo.

Not starting from pvshim_defconfig should always be OK, as the
defconfig file is just a set of options that the user can otherwise
enable manually.

There are two different things that PV_SHIM_EXCLUSIVE accomplishes:
 - Use to remove code blocks or change defines:  for example
   short-circuiting PG_log_dirty to 0.  This should likely be done
   using a different more fine grained set of Kconfig options.
 - Convert pv_shim to a compile time constant: this is the tricky part
   IMO, as such conversion will force DCO and thus make the resulting
   Xen binary no longer what a user would expect when using
   allyesconfig.

> >>>> Or else they may end up with a lot of dead code. (Just consider e.g.
> >>>> HVM=n: We also don't permit HVM-only stuff to be enabled in that case,
> >>>> as any of that would again be dead code then.)
> >>>
> >>> It will always be possible to come up with poor configurations. I do not
> >>> believe it is necessarily our responsibility to go out of our way to
> >>> prevent them.
> >>
> >> Well - if so, why would we do this in some cases but not in others?
> >> You may recall that I'm a proponent of consistency and predictability.
> >>
> >>>>> 2) a pvshim_defconfig target which expresses what a pvshim ought to look
> >>>>> like.
> >>>>
> >>>> We have this file already. I consider it debatable though whether this file
> >>>> should really force PV_SHIM_EXCLUSIVE=y. People may read "pvshim" in the
> >>>> name as either "works just as shim" or "can also work as shim".
> >>>
> >>> If I understood it right, I like Andrew's suggestion. He is suggesting
> >>> to do the following:
> >>>
> >>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
> >>
> >> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
> >> "nothing other than making the boolean be a compile time constant".
> > 
> > Won't making the boolean a compile time constant would also result in
> > DCO kicking in and removing a fair amount of code?  So even if you
> > have enabled everything in Kconfig, the resulting hypervisor would
> > only be suitable to be used as a shim?
> 
> Of course.

Then what's the point of this approach?  Options will be enabled in
Kconfig, but the resulting hypervisor build when using allyesconfig
would have a lot of them short-circuited, making it even worse than
currently?  As options will get effectively build-time disabled due
to DCO while enabled in Kconfig.

Overall I think PV_SHIM_EXCLUSIVE should be excluded from
allyesconfig, even with Andrew's proposed change.  Otherwise the
purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE
makes the resulting hypervisor build PV shim only.  IIRC we can
provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n.

Thanks, Roger.

On 21.01.2025 19:02, Roger Pau Monné wrote:
> On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
>> On 21.01.2025 09:52, Roger Pau Monné wrote:
>>> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
>>>> On 21.01.2025 00:27, Stefano Stabellini wrote:
>>>>> If I understood it right, I like Andrew's suggestion. He is suggesting
>>>>> to do the following:
>>>>>
>>>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
>>>>
>>>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
>>>> "nothing other than making the boolean be a compile time constant".
>>>
>>> Won't making the boolean a compile time constant would also result in
>>> DCO kicking in and removing a fair amount of code?  So even if you
>>> have enabled everything in Kconfig, the resulting hypervisor would
>>> only be suitable to be used as a shim?
>>
>> Of course.
> 
> Then what's the point of this approach?  Options will be enabled in
> Kconfig, but the resulting hypervisor build when using allyesconfig
> would have a lot of them short-circuited, making it even worse than
> currently?  As options will get effectively build-time disabled due
> to DCO while enabled in Kconfig.

Well, I have to direct this question to Andrew. It is specifically
what I'm trying to address with UNCONSTRAINED.

> Overall I think PV_SHIM_EXCLUSIVE should be excluded from
> allyesconfig, even with Andrew's proposed change.  Otherwise the
> purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE
> makes the resulting hypervisor build PV shim only.  IIRC we can
> provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n.

Hmm, I wasn't aware of the option of using allyes.config. That might be
the route to go, albeit it looks like people using the allyesconfig
target then need to remember to set KCONFIG_ALLCONFIG in the environment
(to <empty> or 1), or to explicitly specify a file name that way. (This
of course ought to be easy enough to arrange for in our automation.)

Jan

On Wed, Jan 22, 2025 at 09:43:53AM +0100, Jan Beulich wrote:
> On 21.01.2025 19:02, Roger Pau Monné wrote:
> > On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
> >> On 21.01.2025 09:52, Roger Pau Monné wrote:
> >>> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> >>>> On 21.01.2025 00:27, Stefano Stabellini wrote:
> >>>>> If I understood it right, I like Andrew's suggestion. He is suggesting
> >>>>> to do the following:
> >>>>>
> >>>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
> >>>>
> >>>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
> >>>> "nothing other than making the boolean be a compile time constant".
> >>>
> >>> Won't making the boolean a compile time constant would also result in
> >>> DCO kicking in and removing a fair amount of code?  So even if you
> >>> have enabled everything in Kconfig, the resulting hypervisor would
> >>> only be suitable to be used as a shim?
> >>
> >> Of course.
> > 
> > Then what's the point of this approach?  Options will be enabled in
> > Kconfig, but the resulting hypervisor build when using allyesconfig
> > would have a lot of them short-circuited, making it even worse than
> > currently?  As options will get effectively build-time disabled due
> > to DCO while enabled in Kconfig.
> 
> Well, I have to direct this question to Andrew. It is specifically
> what I'm trying to address with UNCONSTRAINED.
> 
> > Overall I think PV_SHIM_EXCLUSIVE should be excluded from
> > allyesconfig, even with Andrew's proposed change.  Otherwise the
> > purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE
> > makes the resulting hypervisor build PV shim only.  IIRC we can
> > provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n.
> 
> Hmm, I wasn't aware of the option of using allyes.config. That might be
> the route to go, albeit it looks like people using the allyesconfig
> target then need to remember to set KCONFIG_ALLCONFIG in the environment
> (to <empty> or 1), or to explicitly specify a file name that way. (This
> of course ought to be easy enough to arrange for in our automation.)

My knowledge of Kconfig is very limited, but isn't there a default
path for such file to be picked up by Kconfig?  I see we already have
a xen/tools/kconfig/allrandom.config, I was expecting it would be a
matter of dropping an allyes.config in that directory, but I haven't
tried.

Thanks, Roger.

On 22.01.2025 10:49, Roger Pau Monné wrote:
> On Wed, Jan 22, 2025 at 09:43:53AM +0100, Jan Beulich wrote:
>> On 21.01.2025 19:02, Roger Pau Monné wrote:
>>> On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
>>>> On 21.01.2025 09:52, Roger Pau Monné wrote:
>>>>> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
>>>>>> On 21.01.2025 00:27, Stefano Stabellini wrote:
>>>>>>> If I understood it right, I like Andrew's suggestion. He is suggesting
>>>>>>> to do the following:
>>>>>>>
>>>>>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
>>>>>>
>>>>>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
>>>>>> "nothing other than making the boolean be a compile time constant".
>>>>>
>>>>> Won't making the boolean a compile time constant would also result in
>>>>> DCO kicking in and removing a fair amount of code?  So even if you
>>>>> have enabled everything in Kconfig, the resulting hypervisor would
>>>>> only be suitable to be used as a shim?
>>>>
>>>> Of course.
>>>
>>> Then what's the point of this approach?  Options will be enabled in
>>> Kconfig, but the resulting hypervisor build when using allyesconfig
>>> would have a lot of them short-circuited, making it even worse than
>>> currently?  As options will get effectively build-time disabled due
>>> to DCO while enabled in Kconfig.
>>
>> Well, I have to direct this question to Andrew. It is specifically
>> what I'm trying to address with UNCONSTRAINED.
>>
>>> Overall I think PV_SHIM_EXCLUSIVE should be excluded from
>>> allyesconfig, even with Andrew's proposed change.  Otherwise the
>>> purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE
>>> makes the resulting hypervisor build PV shim only.  IIRC we can
>>> provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n.
>>
>> Hmm, I wasn't aware of the option of using allyes.config. That might be
>> the route to go, albeit it looks like people using the allyesconfig
>> target then need to remember to set KCONFIG_ALLCONFIG in the environment
>> (to <empty> or 1), or to explicitly specify a file name that way. (This
>> of course ought to be easy enough to arrange for in our automation.)
> 
> My knowledge of Kconfig is very limited, but isn't there a default
> path for such file to be picked up by Kconfig?  I see we already have
> a xen/tools/kconfig/allrandom.config, I was expecting it would be a
> matter of dropping an allyes.config in that directory, but I haven't
> tried.

Well, I simply looked at the kconfig sources, and my reading of it is
that it won't even try to open allyes.config when the envvar is absent.

Jan

On Wed, 22 Jan 2025, Jan Beulich wrote:
> On 22.01.2025 10:49, Roger Pau Monné wrote:
> > On Wed, Jan 22, 2025 at 09:43:53AM +0100, Jan Beulich wrote:
> >> On 21.01.2025 19:02, Roger Pau Monné wrote:
> >>> On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
> >>>> On 21.01.2025 09:52, Roger Pau Monné wrote:
> >>>>> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> >>>>>> On 21.01.2025 00:27, Stefano Stabellini wrote:
> >>>>>>> If I understood it right, I like Andrew's suggestion. He is suggesting
> >>>>>>> to do the following:
> >>>>>>>
> >>>>>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing
> >>>>>>
> >>>>>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but
> >>>>>> "nothing other than making the boolean be a compile time constant".
> >>>>>
> >>>>> Won't making the boolean a compile time constant would also result in
> >>>>> DCO kicking in and removing a fair amount of code?  So even if you
> >>>>> have enabled everything in Kconfig, the resulting hypervisor would
> >>>>> only be suitable to be used as a shim?
> >>>>
> >>>> Of course.
> >>>
> >>> Then what's the point of this approach?  Options will be enabled in
> >>> Kconfig, but the resulting hypervisor build when using allyesconfig
> >>> would have a lot of them short-circuited, making it even worse than
> >>> currently?  As options will get effectively build-time disabled due
> >>> to DCO while enabled in Kconfig.
> >>
> >> Well, I have to direct this question to Andrew. It is specifically
> >> what I'm trying to address with UNCONSTRAINED.
> >>
> >>> Overall I think PV_SHIM_EXCLUSIVE should be excluded from
> >>> allyesconfig, even with Andrew's proposed change.  Otherwise the
> >>> purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE
> >>> makes the resulting hypervisor build PV shim only.  IIRC we can
> >>> provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n.
> >>
> >> Hmm, I wasn't aware of the option of using allyes.config. That might be
> >> the route to go, albeit it looks like people using the allyesconfig
> >> target then need to remember to set KCONFIG_ALLCONFIG in the environment
> >> (to <empty> or 1), or to explicitly specify a file name that way. (This
> >> of course ought to be easy enough to arrange for in our automation.)
> > 
> > My knowledge of Kconfig is very limited, but isn't there a default
> > path for such file to be picked up by Kconfig?  I see we already have
> > a xen/tools/kconfig/allrandom.config, I was expecting it would be a
> > matter of dropping an allyes.config in that directory, but I haven't
> > tried.
> 
> Well, I simply looked at the kconfig sources, and my reading of it is
> that it won't even try to open allyes.config when the envvar is absent.

Reading the thread, I think that:

- using allyes.config as Roger suggested
- arranging for KCONFIG_ALLCONFIG to be set as needed
- leaving PV_SHIM_EXCLUSIVE as is

is the simplest way forward

Hi all,

The topic was discussed today during the committers and core maintainers
call and the decision was to remove the PV_SHIM_EXCLUSIVE Kconfig
option.

Cheers,

Stefano

On 17.01.2025 01:31, Stefano Stabellini wrote:
> On Wed, 1 Mar 2023, Jan Beulich wrote:
>> While we want certain things turned off in shim-exclusive mode, doing
>> so via "depends on !PV_SHIM_EXCLUSIVE" badly affects allyesconfig: Since
>> that will turn on PV_SHIM_EXCLUSIVE, other options will be turned off as
>> a result. Yet allyesconfig wants to enable as much of the functionality
>> as possible.
>>
>> Retain PV_SHIM_EXCLUSIVE as a prompt-less option such that first of all
>> C code using it can remain as is. This isn't just for less code churn,
>> but also because I think that symbol is more logical to use in many
>> (all?) places.
>>
>> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> ---
>> The new Kconfig control's name is up for improvement suggestions, but I
>> think it's already better than the originally thought of
>> FULL_HYPERVISOR.
> 
> I think the approach in general is OK, maybe we can improve the naming
> further. What about one of the following?
> 
> NO_PV_SHIM_EXCLUSIVE
> PV_SHIM_NOT_EXCLUSIVE
> ADD_PV_SHIM
> PV_SHIM_AND_HYPERVISOR
> 
> This is because I think the option should be tied to PV_SHIM. Keep in
> mind that users are supposed to be able to use "make menuconfig" and
> pick good options based on the menu. An option called UNCONSTRAINED or
> FULL_HYPERVISOR or any other name that has nothing to do with PV_SHIM is
> very confusing to me.

Hmm. That was actually something I was specifically trying to avoid. Imo
the connection to the shim only wants making in the help text. And I fear
I view all your naming suggestions as hard to grok.

Jan