Path: csiph.com!aioe.org!bofh.it!news.nic.it!robomod From: Andrew Cooper Newsgroups: linux.kernel Subject: Re: Getting rid of invalid SYSCALL RSP under Xen? Date: Mon, 27 Jul 2015 01:10:02 +0200 Message-ID: References: X-Original-To: Andy Lutomirski X-Cam-Antivirus: no malware found X-Cam-Scannerinfo: http://www.cam.ac.uk/cs/email/scanner/ X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: robomod@news.nic.it List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Approved: robomod@news.nic.it Lines: 67 Organization: linux.* mail to news gateway X-Original-Cc: X86 ML , Boris Ostrovsky , "linux-kernel@vger.kernel.org" , Borislav Petkov , Steven Rostedt , "xen-devel@lists.xen.org" X-Original-Date: Mon, 27 Jul 2015 00:05:37 +0100 X-Original-Message-ID: <55B567C1.3050709@citrix.com> X-Original-References: <55B53636.80304@citrix.com> X-Original-Sender: linux-kernel-owner@vger.kernel.org Xref: aioe.org linux.kernel:1192580 On 26/07/2015 23:08, Andy Lutomirski wrote: > >>> If so, can we just >>> enter later on: >>> >>> pushq %r11 /* pt_regs->flags */ >>> pushq $__USER_CS /* pt_regs->cs */ >>> pushq %rcx /* pt_regs->ip */ >>> >>> <-- Xen enters here >>> >>> pushq %rax /* pt_regs->orig_ax */ >>> pushq %rdi /* pt_regs->di */ >>> pushq %rsi /* pt_regs->si */ >>> pushq %rdx /* pt_regs->dx */ >> This looks plausible, and indeed preferable to the current doublestep >> with undo_xen_syscall. >> >> One slight complication is that xen_enable_syscall() will want to >> special case register_callback() to not set CALLBACKF_mask_events, as >> the entry point is now after re-enabling interrupts. > I wouldn't do that. Let's just move the ENABLE_INTERRUPTS a few > instructions later even on native -- I want to do that anyway. That would also work. > >>> For SYSRET, I think the way to go is to force Xen to always use the >>> syscall slow path. Instead, Xen could hook into >>> syscall_return_via_sysret or even right before the opportunistic >>> sysret stuff. Then we could remove the USERGS_SYSRET hooks entirely. >>> >>> Would this work? >> None of the opportunistic sysret stuff makes sense under Xen. The path >> will inevitably end up in xen_iret making a hypercall. Short circuiting >> all of this seems like a good idea, especially if it allows for the >> removal of the UERGS_SYSRET. > Doesn't Xen decide what to do based on VGCF_IN_SYSCALL? Maybe Xen > should have its own opportunistic VGCF_IN_SYSCALL logic. VGCF_in_syscall affects whether the extra r11/rcx get restored or not, as the hypercall itself is implemented using syscall. As the extra r11/rcx (and rax for that matter) are unconditionally saved in the hypercall stub, I can't see anything Linux could usefully do, opportunistically speaking. > > Hmm, maybe some of this would be easier to think about if, rather than > having a paravirt op, we could have: > > ALTERNATIVE "", "jmp xen_pop_things_and_iret", X86_FEATURE_XEN > > Or just IF_XEN("jmp ..."); > > As a practical matter, x86_64 has native and Xen -- I don't think > there's any other paravirt platform that needs the asm hooks. It would certainly seem so. A careful use of IF_XEN() or two would make the code far clearer to read, and to drop the hooks. ~Andrew -- 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/