[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 at 11:57, <andrew.cooper3@xxxxxxxxxx> wrote: > 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 don't view this as awkward at all. >> 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. Because of ??? I see no reason to restrict Xen's (or Dom0's) capabilities just because of migration considerations. > 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. Which would make the patch acceptable once that series went in. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |