On Mon, Mar 10, 2025, at 22:01, Michael Kelley wrote:
> From: Arnd Bergmann <arnd@xxxxxxxx> Sent: Saturday, March 8, 2025 1:05 PM
>> > config HYPERV_VTL_MODE
>> > bool "Enable Linux to boot in VTL context"
>> > - depends on X86_64 && HYPERV
>> > + depends on (X86_64 || ARM64)
>> > depends on SMP
>> > + select OF_EARLY_FLATTREE
>> > + select OF
>> > default n
>> > help
>>
>> Having the dependency below the top-level Kconfig entry feels a little
>> counterintuitive. You could flip that back as it was before by doing
>>
>> select HYPERV_VTL_MODE if !ACPI
>> depends on ACPI || SMP
>>
>> in the HYPERV option, leaving the dependency on HYPERV in
>> HYPERV_VTL_MODE.
>
> I would argue that we don't ever want to implicitly select
> HYPERV_VTL_MODE because of some other config setting or
> lack thereof. VTL mode is enough of a special case that it should
> only be explicitly selected. If someone omits ACPI, then HYPERV
> should not be selectable unless HYPERV_VTL_MODE is explicitly
> selected.
>
> The last line of the comment for HYPERV_VTL_MODE says
> "A kernel built with this option must run at VTL2, and will not run
> as a normal guest." In other words, don't choose this unless you
> 100% know that VTL2 is what you want.
It sounds like the latter is the real problem: enabling a feature
should never prevent something else from working. Can you describe
what VTL context is and why it requires an exception to a rather
fundamental rule here? If you build a kernel that runs on every
single piece of arm64 hardware and every hypervisor, why can't
you add HYPERV_VTL_MODE to that as an option?
Arnd
