On Thu Nov 27, 2025 at 9:36 PM CET, Andrew Cooper wrote:
> On 27/11/2025 1:15 pm, Alejandro Vallejo wrote:
>>> Which raises the next question: Should we even allow a hypervisor to be
>>> built
>>> with X86_ENABLED_VENDORS == 0?
>> That's the most extreme case of "should we boot on a CPU known CPU vendor
>> that
>> has been compiled out?", the current code in the RFC uses the unknown vendor
>> as fallback. We could also panic. We could be trying to exercise the
>> "no assumptions about the vendor" paths.
>>
>> It's a policy decision for you (x86 mantainers) to take. I personally think
>> the
>> default path is silly in this day and age and we could get rid of it
>> entirely.
>> Without it X86_ENABLED_VENDORS=0 would be indeed illegal. On that topic...
>
> We allow compiling out both PV and HVM, so Randconfig can search for
> broken corners of the abstraction. The same principle applies here.
That answers how to prevent that configuration from appearing in randconfig,
not whether that configuration should be valid or not. That's what I meant is a
policy decision.
As the RFC stands:
CONFIG POLICY
X86_ENABLED_VENDORS=0 | all boots use the default CPU
UNKNOWN_CPU=y |
X86_ENABLED_VENDORS=0 | panic on boot
UNKNOWN_CPU=n |
X86_ENABLED_VENDORS=<all> | current all-vendors-compiled-in
UNKNOWN_CPU=y |
X86_ENABLED_VENDORS=<all> | Marginal code removal in early_cpu_init() of
UNKNOWN_CPU=n | the default CPU branch.
X86_ENABLED_VENDORS=<more-than-1> | x86_vendor_is() folds into false when
UNKNOWN_CPU=<any> | checking against all-compiled-out vendors
| Also, some &-checks turn into ==-checks.
X86_ENABLED_VENDORS=<single> | Same as the one above.
UNKNOWN_CPU=y |
X86_ENABLED_VENDORS=<single> | x86_vendor_is() folds into constant true/false
UNKNOWN_CPU=n |
Does this sound like a credible approach? What could be different?
- Should we remove the "default" case altogether"? That removes the Kconfig
and simplifies matters somewhat.
- If the default case is to stay, should we allow running with no-explicit
vendors set?
>
> For running such a hypervisor, I can't see anything that would
> fundamentally interfere with PV guests; PV guests are all architectural x86.
You could also run HVM, seeing how SVM and VMX don't intrinsically require AMD
and INTEL respectively, but it wouldn't be pleasant, secure or safe. It would
be wonky at best. In general it's a path I wouldn't like to fallback to on the
basis that it's completely untested. I don't believe OSSTest ever exercised it
(I wouldn't even know how), nor GitlabCI, nor XenRT.
>
> I don't like there being an explicit Kconfig option for UNKNOWN.
> UNKNOWN should simply be "didn't match anything we compiled in".
What I require for the optimisation to fully work out is precisely the removal
of that the "didn't match anything we compiled in" as a plausible successful
boot scenario in order for all x86_vendor_is(x, X86_VENDOR_AMD) to fold into
"true". I could reverse the polarity and have a REQUIRE_KNOWN_VENDOR, but that's
a non additive option that clashes with allyesconfig/allnoconfig.
>
> ~Andrew
Cheers,
Alejandro
