On 27/02/2020 09:40, Jan Beulich wrote: > On 27.02.2020 10:33, Andrew Cooper wrote: >> On 27/02/2020 07:38, Jan Beulich wrote: >>> On 26.02.2020 21:22, Andrew Cooper wrote: >>>> Just as with c/s 96dc77b4b1 for XEN_SYSCTL_get_cpu_policy, >>>> XEN_SYSCTL_get_cpu_featureset needs to become conditional. >>>> >>>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> >>> Reviewed-by: Jan Beulich <jbeul...@suse.com> >>> >>> Albeit I'd say "want", not "needs" in the description. >> It occurs to me that XEN_SYSCTL_get_cpu_featureset is strictly a subset >> of XEN_SYSCTL_get_cpu_policy, and that now I've adjusted the toolstack >> onto get_cpu_policy, the sole remaining user is xen-cpuid. >> >> get_cpu_policy already has separate default and max indices, whereas >> get_cpu_featureset was written before the need for this has become obvious. >> >> This leads to an asymmetry in xen-cpuid, where the -p (policy) option >> provides two more sets of information than the featureset listing. >> >> Instead, I think I'd like to drop XEN_SYSCTL_get_cpu_featureset and >> update the sole user to the more complete interface. > Sounds like a good move to me.
Actually, after having spent almost a day trying to disentangle the remains of this, I'm going to leave it for now. It turns out it is still used by the legacy CPUID logic, and I could do with getting a few other pieces of infrastructure before it is easy to take out. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
