On 04/02/2022 08:31, Jan Beulich wrote:
> On 03.02.2022 19:10, Andrew Cooper wrote:
>> It was Xen 4.14 where CPUID data was added to the migration stream, and 4.13
>> that we need to worry about with regards to compatibility. Xen 4.12 isn't
>> relevant.
>>
>> Expand and correct the commentary.
>>
>> Fixes: 111c8c33a8a1 ("x86/cpuid: do not expand max leaves on restore")
> But doesn't this commit amend 685e922d6f30 ("tools/libxc: Rework
> xc_cpuid_apply_policy() to use {get,set}_cpu_policy()"), which is
> where DEF_MAX_* disappeared?
No. All that happened in that change was that we switched to using
cpuid.h:89:#define CPUID_GUEST_NR_EXTD_AMD
instead, which remained the same size until Xen 4.15 when e9b4fe26364
bumped it.
> While looking at this, wasn't Roger's change incomplete, in that
> for Intel the extended leaf upper bound was 0x80000008 in 4.12?
CPUID_GUEST_NR_EXTD_INTEL is still 8, so this is all fine.
Even if hardware has more, we'll still limit to 8 on Intel. That said,
to this date Intel haven't bumped the limit, so we're approaching 2
decades without change.
Should this change, then yes, we'd have have to adjust the compat path.
~Andrew
