Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751646AbdGZR5q (ORCPT ); Wed, 26 Jul 2017 13:57:46 -0400 Received: from mail-it0-f53.google.com ([209.85.214.53]:38911 "EHLO mail-it0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751395AbdGZR5o (ORCPT ); Wed, 26 Jul 2017 13:57:44 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v1] xen: get rid of paravirt op adjust_exception_frame From: Andy Lutomirski X-Mailer: iPhone Mail (14G60) In-Reply-To: <93384be6-55b8-47e1-0478-150f9c906605@suse.com> Date: Wed, 26 Jul 2017 13:57:42 -0400 Cc: "linux-kernel@vger.kernel.org" , "xen-devel@lists.xenproject.org" , X86 ML , Boris Ostrovsky , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar Message-Id: <3487CD8D-4BC6-46D1-861A-A6FF31EB6087@amacapital.net> References: <20170724142853.26448-1-jgross@suse.com> <93384be6-55b8-47e1-0478-150f9c906605@suse.com> To: Juergen Gross Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v6QHvpVI014819 Content-Length: 1834 Lines: 58 > On Jul 26, 2017, at 11:50 AM, Juergen Gross wrote: > >> On 26/07/17 15:48, Andy Lutomirski wrote: >>> On Mon, Jul 24, 2017 at 7:28 AM, Juergen Gross wrote: >>> When running as Xen pv-guest the exception frame on the stack contains >>> %r11 and %rcx additional to the other data pushed by the processor. >>> >>> Instead of having a paravirt op being called for each exception type >>> prepend the Xen specific code to each exception entry. When running as >>> Xen pv-guest just use the exception entry with prepended instructions, >>> otherwise use the entry without the Xen specific code. >> >> I think this is a nice cleanup, but I'm wondering if it would be even >> nicer if the Xen part was kept out-of-line. That is, could Xen have >> little stubs like: >> >> xen_alignment_check: >> pop %rcx >> pop %r11 >> jmp alignment_check >> >> rather than using the macros in entry_64.S that you have? Then you >> could adjust set_trap_gate instead of pack_gate and maybe even do >> something like: >> >> #define set_trap_gate(..., name, ...) set_native_or_xen_trap_gate(..., >> name, xen_##name, ...) > > I think I'll have something like: > > #define pv_trap_entry(name) (xen_pv_domain() ? xen_ ## name : name) > > and use it like: > > set_intr_gate(X86_TRAP_AC, pv_trap_entry(alignment_check)); > > This will avoid having to define macros for all variants of > set_intr_gate(), e.g. set_intr_gate_ist(), set_system_intr_gate(). > > Do you have any objections? > Sounds good to me. FWIW, I have no real objection to putting the Xen entry right before the native entry and falling through. I don't love the ip -= 3 bit, though, and I think that the PV_ENTRY macro is too magical. This might be okay, though: XEN_PV_ENTRY_FALLTHROUGH(foo) ENTRY(foo) code here > > Juergen