Re: [PATCH] x86/cpuid: prevent decreasing of hypervisor max leaf on migration

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/10/2021 15:00, Roger Pau Monne wrote:
> In order to be compatible with previous Xen versions, and not change
> max hypervisor leaf as a result of a migration, keep the clamping of
> the maximum leaf value provided to XEN_CPUID_MAX_NUM_LEAVES, instead
> of doing it based on the domain type. Also set the default maximum
> leaf without taking the domain type into account. The maximum
> hypervisor leaf is not migrated, so we need the default to not regress
> beyond what might already be reported to a guest by existing Xen
> versions.
>
> This is a partial revert of 540d911c28 and restores the previous
> behaviour and assures that HVM guests won't see it's maximum
> hypervisor leaf reduced from 5 to 4 as a result of a migration.
>
> Fixes: 540d911c28 ('x86/CPUID: shrink max_{,sub}leaf fields according to 
> actual leaf contents')
> Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Thanks.

Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

> ---
> Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>
> ---
> Regarding release risks:
>
> This is a partial revert of a commit.  The main issues could be that a
> partial revert could break the build or leave the remaining code in a
> non-working condition.
>
> Breaking the build will be easily discovered by our automated testing,
> while leaving the remaining code in a broken state is unlikely, as the
> chunks reverted are isolated from the rest of the change in
> 540d911c28.

This fixes a regression vs 4.15.  Furthermore, the changes to the
hypervisor leaves don't even interact with the rest of the patch.

Failure to compile is about the only risk, and this is easy to prove one
way or another.

~Andrew