On 04/02/2022 13:09, Jan Beulich wrote:
> On 04.02.2022 13:12, Andrew Cooper wrote:
>> 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.
> Oh, right. I did try to look for a replacement, but managed to miss
> this. But then, as much as 4.12 isn't relevant, isn't it the case
> that the fact that CPUID data was added to the stream in 4.14 isn't
> relevant here either, and it's instead the bumping in 4.15 which is?
The fact that the bump happened is relevant, by virtue of the fact there
logic added to cope. The fact it was in 4.15 is not relevant - this
isn't a list of every ABI-relevant change.
CPUID data being added to the stream is critically important, because
that's the point after which we never enter this compatibility path.
~Andrew
