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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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).

-boris

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