[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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

~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®.