Re: [Xen-devel] [PATCH v2 1/2] x86/entry/32: Introduce and use X86_BUG_ESPFIX instead of paravirt_enabled

[Andy Lutomirski <luto@xxxxxxxxxxxxxx>]

On Tue, Mar 1, 2016 at 6:00 AM, Boris Ostrovsky
<boris.ostrovsky@xxxxxxxxxx> wrote:
> On 02/29/2016 06:50 PM, Andy Lutomirski wrote:
>>
>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>> index 91ddae732a36..c6ef4da8e4f4 100644
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -979,6 +979,31 @@ static void identify_cpu(struct cpuinfo_x86 *c)
>>   #ifdef CONFIG_NUMA
>>         numa_add_cpu(smp_processor_id());
>>   #endif
>> +
>> +       /*
>> +        * ESPFIX is a strange bug.  All real CPUs have it.  Paravirt
>> +        * systems that run Linux at CPL > 0 may or may not have the
>> +        * issue, but, even if they have the issue, there's absolutely
>> +        * nothing we can do about it because we can't use the real IRET
>> +        * instruction.
>> +        *
>> +        * NB: For the time being, only 32-bit kernels support
>> +        * X86_BUG_ESPFIX as such.  64-bit kernels directly choose
>> +        * whether to apply espfix using paravirt hooks.  If any
>> +        * non-paravirt system ever shows up that does *not* have the
>> +        * ESPFIX issue, we can change this.
>> +        */
>> +#ifdef CONFIG_X86_32
>> +#ifdef CONFIG_PARAVIRT
>> +       do {
>> +               extern void native_iret(void);
>> +               if (pv_cpu_ops.iret == native_iret)
>> +                       set_cpu_bug(c, X86_BUG_ESPFIX);
>> +       } while (0);
>> +#else
>> +       set_cpu_bug(c, X86_BUG_ESPFIX);
>> +#endif
>> +#endif
>>   }
>>     /*
>
>
>
> Alternatively, PV guests can clear X86_BUG_ESPFIX in their init code. E.g in
> .set_cpu_features op, just like we do for X86_BUG_SYSRET_SS_ATTRS (although
> this may require adding struct hypervisor_x86 for lguests. Which I think
> they should have anyway).

I'm fine with that.

Luis, if you prefer that approach, can you do this and add the
resulting patch to your series?  You're busily reworking that stuff
anyway.

>
> -boris



-- 
Andy Lutomirski
AMA Capital Management, LLC

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