Re: [PATCH RFC 5/9] x86/traps: Functional prep work

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 15/05/14 11:36, Jan Beulich wrote:
>>>> On 15.05.14 at 11:48, <andrew.cooper3@citrix.com> wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -558,6 +558,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>          .stop_bits = 1
>>      };
>>  
>> +    set_processor_id(0);
>> +    set_current((struct vcpu *)0xfffff000); /* debug sanity */
>> +    this_cpu(curr_vcpu) = idle_vcpu[0] = current;
> The this_cpu() part wasn't there in the original code - is that really
> needed, and ...

I was attempting to go for similarity between __start_xen and
start_secondary, which reminds me I need a further fix regarding cr4,
which still loads CR4.MCE on APs before having a TRAP_machine_check
handler available.

>
>> +
>> +    sort_exception_tables();
>> +
>>      percpu_init_areas();
> ... is that really safe/meaningful before this function got called?
>
> Jan
>

There is no specific relationship between sort_exception_tables() and
percpu_init_areas(), both of which are tweaking well defined state
inside the .data section.

sort_excetpion_tables() is a prerequisite for getting extable fixups to
work in the trap handlers, but as indicated, it would be nice to turn it
into something more like "assert exception tables are sorted" and making
the linker do the work.

~Andrew