[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC 28/31] xen/x86: Context switch all levelling state in context_switch()
>>> On 22.01.16 at 15:19, <andrew.cooper3@xxxxxxxxxx> wrote: > On 22/01/16 09:52, Jan Beulich wrote: >>>>> On 16.12.15 at 22:24, <andrew.cooper3@xxxxxxxxxx> wrote: >>> @@ -145,6 +145,13 @@ void intel_ctxt_switch_levelling(const struct domain >>> *nextd) >>> struct cpumasks *these_masks = &this_cpu(cpumasks); >>> const struct cpumasks *masks = &cpumask_defaults; >>> >>> + if (cpu_has_cpuid_faulting) { >>> + set_cpuid_faulting(nextd && is_pv_domain(nextd) && >>> + !is_control_domain(nextd) && >>> + !is_hardware_domain(nextd)); >>> + return; >>> + } >> Considering that you don't even probe the masking MSRs, this seems >> inconsistent with your "always level the entire system" choice. > > In the case that faulting is available, we never want to touch masking. > Faulting is newer and strictly superior to masking. > > As documented, there is no hardware which support both. (In reality, > there is one SKU of IvyBridge CPUs which experimentally have both.) > > > The fact that dom0 and the hardware domain are bypassed is a bug IMO. And we appear to disagree here. I'd rather see the rest of the series match this current behavior. > However, I am preserving the existing behaviour until phase 2 when I fix > other parts of the cpuid policy. Currently imposing faulting on dom0 > causes carnage because nothing generates it a sane policy. > > ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |