Re: [Xen-devel] [PATCH RFC 27/31] xen/x86: Rework Intel masking/faulting setup

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.01.16 at 15:46, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/01/16 14:29, Jan Beulich wrote:
>>>>> On 22.01.16 at 15:09, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 22/01/16 09:40, Jan Beulich wrote:
>>>>>>> On 16.12.15 at 22:24, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> @@ -183,22 +237,13 @@ static void early_init_intel(struct cpuinfo_x86 *c)
>>>>>       (boot_cpu_data.x86_mask == 3 || boot_cpu_data.x86_mask == 4))
>>>>>           paddr_bits = 36;
>>>>>  
>>>>> - if (c == &boot_cpu_data && c->x86 == 6) {
>>>>> -         if (probe_intel_cpuid_faulting())
>>>>> -                 __set_bit(X86_FEATURE_CPUID_FAULTING,
>>>>> -                           c->x86_capability);
>>>>> - } else if (boot_cpu_has(X86_FEATURE_CPUID_FAULTING)) {
>>>>> -         BUG_ON(!probe_intel_cpuid_faulting());
>>>>> -         __set_bit(X86_FEATURE_CPUID_FAULTING, c->x86_capability);
>>>>> - }
>>>>> + if (c == &boot_cpu_data)
>>>>> +         intel_init_levelling();
>>>>> +
>>>>> + if (test_bit(X86_FEATURE_CPUID_FAULTING, boot_cpu_data.x86_capability))
>>>>> +            __set_bit(X86_FEATURE_CPUID_FAULTING, c->x86_capability);
>>>> So you intentionally delete the validation of CPUID faulting being
>>>> available on APs?
>>> Yes.  All this does is change where Xen crashes, in the case that AP's
>>> have different capabilities to the BSP, and allows more startup code to
>>> move into __init.
>> So where did that Xen crash point move to (since I didn't spot it)?
> 
> set_cpuid_faulting() doesn't use safe MSR accesses, so would crash on
> first use in a mixed setup.

Oh, that's pretty implicit.

> I could extend it to ASSERT(cpu_has_cpuid_faulting) if you would prefer.

If you don't mind, I'd indeed prefer this to be explicit (perhaps
even using BUG_ON() instead of ASSERT()).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel