Re: [PATCH] tools/guest: Fix comment regarding CPUID compatibility

[Andrew Cooper <amc96@xxxxxxxx>]

On 04/02/2022 13:46, Jan Beulich wrote:
> 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.

Yes, it would have been.

It wasn't an accident that none of the max leaves changed while doing
the Xen CPUID work.

We're unfortunately a long way behind on Intel CPUID leaves, but all(?)
of the new leaves need more complicated migration safely logic than the
toolstack currently knows how to do.

> But anyway, just to be done with this:
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks.

~Andrew