On 01/10/2024 1:37 pm, Alejandro Vallejo wrote:
> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
> index f033d22785be..63bc96451d2c 100644
> --- a/xen/lib/x86/policy.c
> +++ b/xen/lib/x86/policy.c
> @@ -15,7 +15,16 @@ int x86_cpu_policies_are_compatible(const struct
> cpu_policy *host,
> #define FAIL_MSR(m) \
> do { e.msr = (m); goto out; } while ( 0 )
>
> - if ( guest->basic.max_leaf > host->basic.max_leaf )
> + /*
> + * Old AMD hardware doesn't expose topology information in leaf 0xb. We
> + * want to emulate that leaf with credible information because it must be
> + * present on systems in which we emulate the x2APIC.
> + *
> + * For that reason, allow the max basic guest leaf to be larger than the
> + * hosts' up until 0xb.
> + */
> + if ( guest->basic.max_leaf > 0xb &&
> + guest->basic.max_leaf > host->basic.max_leaf )
> FAIL_CPUID(0, NA);
>
> if ( guest->feat.max_subleaf > host->feat.max_subleaf )
This isn't appropriate. You're violating the property that a guest
policy should be bounded by the max (called host here).
Instead, the max policies basic.max_leaf should be at least 0xb.
This is another case where the max wants to be higher with default
inheriting from host.
But it occurs to me that with max being an not-sane-in-isolation policy
anyway, we probably want to end up setting max->$foo.max_leaf to the
appropriate ARRAY_SIZE()'s.
For any leaves within the bounds that Xen knows, it's fine for the
toolstack to set values there even beyond host max leaf, as long as it
doesn't violate other consistency checks.
So, please fix this by adjusting
calculate_{pv,hvm}_{max,default}_policy() in Xen.
Sadly I think it will end up a tad ugly, but don't worry too much.
We've got a number of host==default but max special fields, and I'm
wanting to get a few more examples before choosing how best to
rationalise it to reduce opencoding.
~Andrew
