On 27/01/2020 14:51, Jan Beulich wrote: > On 27.01.2020 15:34, Andrew Cooper wrote: >> With all other pieces in place, it is now safe to restore the CPUID and MSR >> data in the migration stream, rather than discarding them and using the >> higher >> level toolstacks compatibility logic. >> >> While this is a small patch, it has large implications for migrated/resumed >> domains. Most obviously, the CPU family/model/stepping data, >> cache/tlb/etc. will no longer change behind the guests back. >> >> Another change is the interpretation of the Xend cpuid strings. The 'k' >> option is not a sensible thing to have ever supported, and 's' is how how the >> stream will end up behaving. > I'm a little confused I guess - I'd have expected such a description > to mean that ... > >> --- a/tools/libxc/xc_cpuid_x86.c >> +++ b/tools/libxc/xc_cpuid_x86.c >> @@ -291,10 +291,9 @@ int xc_set_domain_cpu_policy(xc_interface *xch, >> uint32_t domid, >> * '0' -> force to 0 >> * 'x' -> we don't care (use default) >> * 'k' -> pass through host value >> - * 's' -> pass through the first time and then keep the same value >> - * across save/restore and migration. >> + * 's' -> legacy alias for 'k' > ... 's' remains documented as is, and 'k' to become a legacy alias.
Given that s has never worked in the past, k is the only plausible one used by people. As they mean the same now, we could specify it either way around, but this way round gives users less work to do. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
