Thread (1 message) 1 message, 1 author, 2015-12-15

Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit

From: Andy Lutomirski <luto@amacapital.net>
Date: 2015-12-15 21:27:28
Also in: lkml

On Tue, Dec 15, 2015 at 12:40 PM, Andrew Cooper
[off-list ref] wrote:
On 19/11/15 22:07, Andy Lutomirski wrote:
quoted
On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky
[off-list ref] wrote:
quoted
The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the
earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit
(and sysret32 in compat mode) pv ops, as suggested by Andy.

As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not
used anymore by anyone and so can be removed.
This whole series is:

Acked-by: Andy Lutomirski <luto@kernel.org>

Now I just have to sucker someone into getting rid of
PARAVIRT_ADJUST_EXCEPTION_FRAME (by using stub entries) and the
overcomplicated syscall entry stuff.  :)
Looking at this, it should be quite easy now.

ALTERNATIVE "", "pop %rcx; %pop %11", X86_FEATURE_XENPV

(Completely untested)
Can't we do one better, though?  Generate a pile of stubs that do the
pops and jump into the normal native asm path.  Admittedly, that's a
lot more work, and I think that the ALTERNATIVE thing you're
suggesting would be a nice improvement.
quoted
And whoever gets rid of
PARAVIRT_ADJUST_EXCEPTION_FRAME gets to wonder why it doesn't crash
and burn for NMIs on Xen, since I'm reasonably confident that it can't
possibly be correct.
The Xen PV ABI only has a single kernel stack pointer which may be
registered.  There is no equivalent of an IST, so if a second fault
occurs, it is delivered normally on the current stack.

By the looks of it, the other NMI handling is ambivalent to the fact
that it isn't really on an IST stack under Xen.
I'll try to find some time to look at it.

--Andy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help