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:You need:
On Tue, Jul 15, 2014 at 08:26:41AM -0700, Andy Lutomirski wrote:
Xen doesn't call start_secondary.Duh!
Cc: stable@xxxxxxxxxxxxxxxI think just disallowing would be preferrable.
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've been looking at sigreturn_64 and it seems to be crashing dom0 (with
both mine and your patches). In kprobe_int3_handler().
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.