[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/2] x86/cpu: Move set_cpumask() calls into c_early_init()
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |