[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] tools/guest: Fix comment regarding CPUID compatibility
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 <jbeulich@xxxxxxxx> Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |