On Tue, Dec 15, 2015 at 12:40 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: > On 19/11/15 22:07, Andy Lutomirski wrote: >> On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky >> <boris.ostrovsky@xxxxxxxxxx> wrote: >>> 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@xxxxxxxxxx> >> >> 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. > >> 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
