Re: [PATCH v2 1/4] x86: provide an inverted Kconfig control for shim-exclusive mode

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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