Re: [PATCH] x86_64,xen,espfix: Initialize espfix on secondary CPUs

From: Boris Ostrovsky
Date: Tue Jul 15 2014 - 12:03:07 EST


On 07/15/2014 11:54 AM, Andy Lutomirski wrote:
On Tue, Jul 15, 2014 at 8:45 AM, Boris Ostrovsky
<boris.ostrovsky@xxxxxxxxxx> wrote:
On 07/15/2014 11:38 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Jul 15, 2014 at 08:26:41AM -0700, Andy Lutomirski wrote:
Xen doesn't call start_secondary.
Duh!
Cc: stable@xxxxxxxxxxxxxxx
Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
---

espfix still doesn't seem to work on Xen (it goes boom in some way that
I don't understand right now), but initializing all CPUs instead of just
one of them seems like a good start.

ISTM the right fix is probably to shove the espfix logic into
native_iret and to tweak the paravirt logic so that native_iret always
gets invoked. I suspect that Xen will need its own implementation of
espfix64 in the hypervisor and that, ultimately, someone may want to
stop initializing espfix64 at all on Xen guests.
I think just disallowing would be preferrable.

I've been looking at sigreturn_64 and it seems to be crashing dom0 (with
both mine and your patches). In kprobe_int3_handler().
You need:

http://lkml.kernel.org/g/c4e339882c121aa76254f2adde3fcbdf502faec2.1405099506.git.luto@xxxxxxxxxxxxxx

The newer version of sigreturn_32 that I pushed is a much better test
-- it tests the 64-bit cases (yay thunks!) and works on kernels
without my SS sigcontext fix.

Yes, that does it. At least we don't have yet another failure mode with this, which was the biggest concern.

Thanks.

-boris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/