|
[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 |