On 04.02.2022 14:34, Andrew Cooper wrote:
> 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.
If the bump happened before CPUID data was added to the stream, logic to
cope with migrating-in guests would have been required too, wouldn't it.
But anyway, just to be done with this:
Acked-by: Jan Beulich <jbeul...@suse.com>
Jan
