Re: XEN_SYSCTL_cpu_policy_hvm_default truncates leaf count

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 01/07/2021 11:56, Olaf Hering wrote:
> For some reason migration of HVM domUs from pre-4.14 to staging is broken.
>
> It seems xc_cpuid_apply_policy gets nr_leaves=119 from 
> XEN_SYSCTL_get_cpu_policy.
> Later XEN_SYSCTL_cpu_policy_hvm_default truncates this value to 31.

119 is the maximum number of leaves to cover sizeof(struct cpuid_policy).

But no CPU hits both Intel and AMD max leaf, so we can unambiguously
represent the policy with fewer than 119 leaves.  31 is the count of
leaves with data in, on this particular system.

> As a result x86_cpuid_copy_to_buffer returns -ENOBUFS. It would copy up to 51 
> leaves in my testing.
>
> I suspect commit 34990446ca91d9e201ff17bd4e3f43bfe3ad308e just revealed a 
> logic error somewhere.
>
> What is supposed to happen in libxl__srm_callout_callback_static_data_done 
> when XGR_SDD_MISSING_CPUID is set?

One of the many totally broken things about Xen migration was that the
guests CPUID data never used to be part of the stream.  It was always
reinvented from scratch on the destination host.

This had fun properties such as the CPU's family/model/stepping changing
underfoot (I'm still amazed that VMs didn't complain more about this -
windows would happily install a new HAL driver and call itself done),
and less fun properties where some features just disappeared totally due
to changes in xc_cpuid_apply_policy() logic.

Starting in 4.14, after I'd added a "please get the guest's view of
CPUID" hypercall, the CPUID settings the VM saw move in the migrate
stream with it.

XGR_SDD_MISSING_CPUID is the signal of "this is a pre-4.14 VM with no
CPUID data", which means "you need to reinvent CPUID as the toolstack in
4.13 would have done".

This *ought* to be "grab default, edit a few details, send back to
Xen".  Where is the 51 leaves coming in?  Do you have cpuid= lines in
the xl cfg file?

~Andrew