|
[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 |