On 22/01/16 14:31, Jan Beulich wrote:
>>>> On 22.01.16 at 15:19, <andrew.coop...@citrix.com> wrote:
>> On 22/01/16 09:52, Jan Beulich wrote:
>>>>>> On 16.12.15 at 22:24, <andrew.coop...@citrix.com> 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.
I am planning to fix it, but it is the same quantity of work again, on
top of this series. I am deliberately not conflating all of the cpuid
related fixes into one series, because it is simply too much work to do
in one go.
Dom0 still gets its "feature levelled" system via emulated cpuid, just
as it does at the moment.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
