On 30.10.2023 16:23, Roger Pau Monné wrote: > On Mon, Oct 30, 2023 at 04:19:22PM +0100, Jan Beulich wrote: >> On 30.10.2023 16:14, Roger Pau Monné wrote: >>> On Mon, Oct 30, 2023 at 01:24:52PM +0100, Jan Beulich wrote: >>>> On 26.10.2023 17:19, Roger Pau Monné wrote: >>>>> Maybe the issue is that PV_SHIM_EXCLUSIVE shouldn't have been a >>>>> Kconfig option in the first place, and instead a specific Kconfig >>>>> config file? >>>>> >>>>> Maybe it's not possible to achieve the same using just a Kconfig >>>>> config file. >>>> >>>> I'm afraid I don't understand what you mean by "Kconfig config file". It >>>> can't really be just another .../Kconfig file somewhere in the tree, as >>>> it doesn't really matter where an option like this would be defined. >>> >>> No, I was thinking of splitting what PV_SHIM_EXCLUSIVE actually >>> implies, for example by adding CONFIG_DOMCTL_HYPERCALLL or >>> CONFIG_PLATFORM_HYPERCALL and re-work the pvshim_defconfig config file >>> based on those, so that we don't end up with negative relations. >>> >>> Note sure all usages of PV_SHIM_EXCLUSIVE can be split in such a way, >>> maybe we would need some compromise. >> >> Wouldn't such a CONFIG_DOMCTL_HYPERCALL then still want to depend on >> !PV_SHIM_EXCLUSIVE, which is the kind of dependency we want to avoid? >> Aiui the two (splitting and inverting) are largely orthogonal aspects. > > No, CONFIG_DOMCTL_HYPERCALL could be promptless option enabled by > default and disabled by the pvshim_defconfig.
pvshim_defconfig shouldn't play a role here. Anyone configuring a shim build from scratch should also get a consistent set of settings. When there's no prompt and default-enabling, I'm also having some difficulty seeing how pvshim_defconfig could override that then. Jan
