On 26/11/2025 4:44 pm, Alejandro Vallejo wrote:
> While in principle it's possible to have a vendor virtualising another,
> this is fairly tricky in practice. Not doing so enables certain
> optimisations with regards to vendor checks in later patches.
>
> Signed-off-by: Alejandro Vallejo <[email protected]>
> ---
> I originally had a Kconfig option to allow cross-vendor virt and
> conditionally disable the check on policy compatibility. In practice,
> I suspect there's 0% of people that would want that, so I decided to
> simply remove it altogether. Happy to put it back if there's anyone
> interested.
We've debated dropping cross-vendor support several times.
Prior to speculation, it was actually the case that PV guests worked
fairly well (Xen abstracts away the details surprisingly well), and HVM
functioned to a first approximation (emulating the SYS* instructions is
horrible).
After speculation, there's no hope in hell of getting a viable VM in a
cross-vendor environment, so we should drop it.
In addition to this hunk, you'll want to drop is_cross_vendor(),
should_emulate logic in hvm_ud_intercept(), and the cross-vendor aspect
of determining #UD interception in {svm,vmx}_cpuid_policy_changed().
Also, I think you can clean up MSR_IA32_PLATFORM_ID / MSR_AMD_PATCHLEVEL
in guest_rdmsr() which have some pretty well hidden is-cross-vendor checks.
Also you'll want a note in CHANGELOG.md.
I'd also suggest splitting it out of this series. It's quite different
to the rest of the series.
~Andrew
