Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933749AbbLOV12 (ORCPT ); Tue, 15 Dec 2015 16:27:28 -0500 Received: from mail-ob0-f177.google.com ([209.85.214.177]:33514 "EHLO mail-ob0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933725AbbLOV1Z (ORCPT ); Tue, 15 Dec 2015 16:27:25 -0500 MIME-Version: 1.0 In-Reply-To: <56707ACE.9060809@citrix.com> References: <1447970147-1733-1-git-send-email-boris.ostrovsky@oracle.com> <56707ACE.9060809@citrix.com> From: Andy Lutomirski Date: Tue, 15 Dec 2015 13:27:05 -0800 Message-ID: Subject: Re: [Xen-devel] [PATCH v2 0/3] Fix and cleanup for 32-bit PV sysexit To: Andrew Cooper Cc: Boris Ostrovsky , "linux-kernel@vger.kernel.org" , Linux Virtualization , Ingo Molnar , David Vrabel , Andrew Lutomirski , "H. Peter Anvin" , "xen-devel@lists.xenproject.org" , Thomas Gleixner , Borislav Petkov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2023 Lines: 51 On Tue, Dec 15, 2015 at 12:40 PM, Andrew Cooper wrote: > On 19/11/15 22:07, Andy Lutomirski wrote: >> On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky >> 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 >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/