On 09/11/2018 17:16, Andrew Cooper wrote: > >> However, one >> issue already might be that in order for bits in a (sub)leaf above >> (guest) limits to come out all clear, it is guest_cpuid() which cuts >> things off. Neither cpuid_featureset_to_policy() nor its inverse >> nor sanitise_featureset() look to zap fields above limits, in case >> they've been previously set to non-zero values. Am I overlooking >> something? > No - that is an aspect I'd overlooked, because the > DOMCTL_set_cpuid_policy work (which does this correctly) hasn't gone in yet. > > I think I'll tweak recalculate_misc() to zero out beyond the max_subleaf > settings, because the intention was always that a flat cpuid_policy was > safe to use in this manner. I think there is an existing corner case > when trying to level basic.max_leaf to < 7, or extd.max_leaf to < 0x8000007.
Actually, I remember now that I tried fixing this once before. It's not possible without DOMCTL_set_cpu_policy because the current API with DOMCTL_set_cpuid provides leaves piecewise and there is no point at which Xen can safely zero the out-of-range leaves without loosing information later if max_leaf is increased. The content of cpuid_policy will be safe for the emulator to use, because it will be bounded by real hardware support. As levelling like this is an extreme corner case which doesn't work at the moment for other reasons, I'd like to take this series now and fix up the behaviour later, to reduce the dependencies in the remaining CPUID/MSR work - its already complicated enough. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
