[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 1/2] x86/entry/32: Introduce and use X86_BUG_ESPFIX instead of paravirt_enabled
On Tue, Mar 01, 2016 at 07:44:10AM -0800, Andy Lutomirski wrote: > 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. I would if I was certain of some things and I also understood this really well, sadly I don't, but I'll ask questions and we'll see. Replies to follow the thread. Luis _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |