[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.