Re: [Xen-devel] [PATCH 2/2] x86/cpu: Move set_cpumask() calls into c_early_init()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/11/15 08:28, Jan Beulich wrote:
>>>> On 26.11.15 at 17:59, <andrew.cooper3@xxxxxxxxxx> wrote:
>> Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the
>> commandline-provided masks would take effect in Xen's view of the features.
>>
>> As the masks got applied after the query for features, the redundant call to
>> generic_identify() would clobber the wrong feature information with the new,
>> correct information.
> I'm seriously wondering: Why would the un-adjusted feature
> information be wrong for Xen's own use (and perhaps even Dom0's)?

There is at least one situation when levelling PV guests where you
absolutely do need to level Xen alongside.

Intel mask msrs cannot hide CPUID.1.ECX[OSXSAVE], as the copy from cr4
happens after the mask is applied, rather than before.

The only way to safely level systems with mixed xsave/non-xsave hardware
is to prevent Xen from turning it on in the first place.  This could be
special cased using the "xsave" command line option, but that is just
awkward.

> I view it exactly the other way around: Said commit actually fixed
> this misbehavior.

I am firmly of the opinion that Xen not respecting the mask options for
itself is misbehaviour.

With my feature levelling series (which is just about together now and
undergoing testing), I don't expect anyone to used the cpuid_mask_*
command line options in general, because the adjustments are made
dynamically on a per-guest basis.

This leaves the use of the command line options for debugging (which
used to work), and for actually making the hardware pretend to be older
hardware, which IMO is the expectation of using the options.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel