On Fri Jul 18, 2025 at 5:41 PM CEST, Andrew Cooper wrote:
> On 18/07/2025 4:12 pm, Alejandro Vallejo wrote:
>> Otherwise compile-time errors ensue. It's a nonsensical configuration,
>> but it's supriously triggered in randconfig jobs.
>>
>> Fixes: 8b5b49ceb3d9("x86: don't include domctl and alike in shim-excl...")
>> Signed-off-by: Alejandro Vallejo <alejandro.garciavall...@amd.com>
>> ---
>> xen/arch/x86/hvm/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/xen/arch/x86/hvm/Kconfig b/xen/arch/x86/hvm/Kconfig
>> index b903764bda..f57a87bca3 100644
>> --- a/xen/arch/x86/hvm/Kconfig
>> +++ b/xen/arch/x86/hvm/Kconfig
>> @@ -1,6 +1,7 @@
>> menuconfig HVM
>> bool "HVM support"
>> default !PV_SHIM
>> + depends on !PV_SHIM_EXCLUSIVE
>> select COMPAT
>> select IOREQ_SERVER
>> select MEM_ACCESS_ALWAYS_ON
>
> I deeply regret not nacking this originally and blocking the patch you
> listed as fixed.
>
> This depends was explicitly reverted in 568f806cba4c because it breaks a
> lot of things, notably `make allyesconfig`.
>
> We're going to need to find a different way to fix RANDCONFIG.
>
> ~Andrew
It can be done the other way around. PV_SHIM_EXCLUSIVE depending on !CONFIG_HVM,
but that won't help with allyesconfig.
PV_SHIM_EXCLUSIVE could be replaced by a PVSHIM_BOOT Kconfig. Combined with
DOM0LESS_BOOT and DOM0_BOOT this gives the full freedom of booting in shim mode,
in dom0 mode, or in dom0less/hlaunch mode; and is compatible with allyesconfig.
PV_SHIM_EXCLUSIVE would be unsetting DOM0_BOOT and DOM0LESS_BOOT.
Not that I want to do it right now. But it sounds like a nicer solution than the
current mess.
Cheers,
Alejandro
