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

["Luis R. Rodriguez" <mcgrof@kernel.org>]

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@oracle.com> 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@lists.xen.org
http://lists.xen.org/xen-devel