On Fri, Feb 04, 2022 at 02:10:03PM +0000, Andrew Cooper wrote:
> 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 <[email protected]>
>
> Thanks.
Will rebase my CPUID series on top of this, but I will wait for
further comments before sending a new version.
Roger.
