Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751701AbcCFSUx (ORCPT ); Sun, 6 Mar 2016 13:20:53 -0500 Received: from smtp.citrix.com ([66.165.176.89]:25724 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751138AbcCFSUq (ORCPT ); Sun, 6 Mar 2016 13:20:46 -0500 X-IronPort-AV: E=Sophos;i="5.22,547,1449532800"; d="scan'208";a="336944900" Subject: Re: [PATCH v2 07/10] x86/entry: Vastly simplify SYSENTER TF handling To: Andy Lutomirski , Brian Gerst References: <20160306165546.GA6902@pd.tnic> CC: Borislav Petkov , Andy Lutomirski , "the arch/x86 maintainers" , Linux Kernel Mailing List , Oleg Nesterov From: Andrew Cooper Message-ID: <56DC74FC.4020302@citrix.com> Date: Sun, 6 Mar 2016 18:20:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1848 Lines: 46 On 06/03/16 17:36, Andy Lutomirski wrote: > >> I haven't read the Xen hypervisor code, but what are those 5 words >> that were pushed on the stack by the hypervisor? It suspiciously is >> the size of an IRET frame. > I think it is nominally an IRET frame. It is a notminal IRET frame. Even to this day, Xen doesn't support anything other "making it appear as if an interrupt/exception occurred", even with the syscall/sysenter and artificial entrypoints. The Xen entrypoint logic predates the introduction of the syscall/sysenter support in Linux. At the point where your hammer is already iret shaped and you have a forked version of Linux for running as a guest, modifying sysenter to be iret shaped is an easy option. For better or worse, this is now the ABI. > One might wonder what's in it, given that the hypervisor doesn't know what the old IP or SP was. Looking at the code which synthesizes the iret frame pushq $FLAT_USER_SS pushq $0 pushfq pushq $3 /* ring 3 null cs */ pushq $0 /* null rip */ Completely ignoring it definitely the best course of action. > >> Considering that we don't use SYSEXIT on >> Xen anymore, can we just redirect SYSENTER to the INT80 handler? >> Perhaps even just disable SYSENTER support in the VDSO on Xen. I >> can't imagine SYSENTER is any faster than INT80 on Xen, because it has >> to trap to the hypervisor first. >> > I think we should leave it enabled -- having user programs on Xen PV > trap into the hypervisor for a system call using SYSENTER will still > be much faster than using INT $0x80 as long as the hypervisor does > something reasonable. The trap into Xen has to happen either way (even for the INT $0x80 path). There is almost certainly room for improvement in both paths, but in principle the sysenter path will be faster. ~Andrew