Re: [PATCH] x86/cpu-policy: Fix migration from Ice Lake to Cascade Lake

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, May 07, 2024 at 12:29:57PM +0100, Andrew Cooper wrote:
> Ever since Xen 4.14, there has been a latent bug with migration.
> 
> While some toolstacks can level the features properly, they don't shink
> feat.max_subleaf when all features have been dropped.  This is because
> we *still* have not completed the toolstack side work for full CPU Policy
> objects.
> 
> As a consequence, even when properly feature levelled, VMs can't migrate
> "backwards" across hardware which reduces feat.max_subleaf.  One such example
> is Ice Lake (max_subleaf=2 for INTEL_PSFD) to Cascade Lake (max_subleaf=0).
> 
> Extend the host policy's feat.max_subleaf to the hightest number Xen knows
> about, similarly to how we extend extd.max_leaf for LFENCE_DISPATCH.  This
> will allow VMs with a higher feat.max_subleaf than strictly necessary to
> migrate in.

Seeing what we do for max_extd_leaf, shouldn't we switch to doing what
you propose for feat.max_subleaf to max_extd_leaf also?

To allow migration between hosts that have 0x80000021.eax and hosts
that don't have such extended leaf.

cpu_has_lfence_dispatch kind of does that, but if lfence cannot be
made serializing then the max extended leaf is not expanded.  And we
should also likely account for more feature leafs possibly appearing
after 0x80000021?

Thanks, Roger.