From patchwork Thu Dec 1 16:55:58 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 9456549 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 7389F60235 for ; Thu, 1 Dec 2016 17:03:58 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 622FD28517 for ; Thu, 1 Dec 2016 17:03:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 56FDE28519; Thu, 1 Dec 2016 17:03:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 9D13C28517 for ; Thu, 1 Dec 2016 17:03:57 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCUiQ-00080V-VF; Thu, 01 Dec 2016 17:00:10 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCUiP-0007xo-FS for xen-devel@lists.xen.org; Thu, 01 Dec 2016 17:00:09 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 62/01-23854-81750485; Thu, 01 Dec 2016 17:00:08 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeJIrShJLcpLzFFi42JxWrohUlci3CH C4P1FToslHxezODB6HN39mymAMYo1My8pvyKBNeP55bWsBS+MK26e2MLcwHhbvYuRg0NCwF/i 7E72LkZODjYBfYndLz4xgdgiAuoSpzsusnYxcnEwC1xglPjy9xlYkbBAkMT61lmMIDaLgIrE0 8NtrCA2r4CnxKGuqWDNEgJyEueP/2QGsTkFvCTOH/rCAmILAdW8bDzBCGGrSVzrv8QO0SsocX LmE7AaZgEJiYMvXjBPYOSdhSQ1C0lqASPTKkb14tSistQiXTO9pKLM9IyS3MTMHF1DA2O93NT i4sT01JzEpGK95PzcTYzA0KlnYGDcwXilzfkQoyQHk5Io7yM9hwghvqT8lMqMxOKM+KLSnNTi Q4wyHBxKEryTQoFygkWp6akVaZk5wCCGSUtw8CiJ8CqEAKV5iwsSc4sz0yFSpxgVpcR5w0D6B EASGaV5cG2wyLnEKCslzMvIwMAgxFOQWpSbWYIq/4pRnINRSZi3D2QKT2ZeCdz0V0CLmYAWd1 y3B1lckoiQkmpg5L8vJHtzrskSFuVPKXPCyg0L0v8ZCalncAuaT3Q+EcP8yIVhf0F5c6vo3N5 7nk//zo40zbfvPbDhnqXsrpl6tqcS0mKOP87c5HFr87srE5W0fyiFxiSfbXetnVA9N+q0448w 2QMSLfmlPzdeSOo4Wb5gyhuejXxP/tlpRP48K1Nde3CRUZKlEktxRqKhFnNRcSIAq/KEsJcCA AA= X-Env-Sender: prvs=136206f05=Andrew.Cooper3@citrix.com X-Msg-Ref: server-15.tower-31.messagelabs.com!1480611604!69970265!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 9.0.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8843 invoked from network); 1 Dec 2016 17:00:07 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Dec 2016 17:00:07 -0000 X-IronPort-AV: E=Sophos;i="5.33,282,1477958400"; d="scan'208";a="392520351" From: Andrew Cooper To: Xen-devel Date: Thu, 1 Dec 2016 16:55:58 +0000 Message-ID: <1480611361-15294-3-git-send-email-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1480611361-15294-1-git-send-email-andrew.cooper3@citrix.com> References: <1480611361-15294-1-git-send-email-andrew.cooper3@citrix.com> MIME-Version: 1.0 Cc: Andrew Cooper , Boris Ostrovsky , Tim Deegan , Suravee Suthikulpanit , Jan Beulich Subject: [Xen-devel] [PATCH v4 10/24] x86/emul: Always use fault semantics for software events X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP The common case is already using fault semantics out of x86_emulate(), as that is how VT-x/SVM expects to inject the event (given suitable hardware support). However, x86_emulate() returning X86EMUL_EXCEPTION and also completing a register writeback is problematic for callers. Switch the logic to always using fault semantics, and leave svm_inject_trap() to fix up %eip if necessary. Signed-off-by: Andrew Cooper Reviewed-by: Boris Ostrovsky Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Tim Deegan CC: Boris Ostrovsky CC: Suravee Suthikulpanit v4: * s/eip/rip/ * Zero the high bits of regs->rip and vmcb->nextrip outside of 64bit mode. * Spelling fixes v3: * New --- xen/arch/x86/hvm/svm/svm.c | 60 ++++++++++++++++++++++------------ xen/arch/x86/x86_emulate/x86_emulate.c | 2 -- xen/arch/x86/x86_emulate/x86_emulate.h | 8 ++++- 3 files changed, 46 insertions(+), 24 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 912d871..8c4f3c7 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1209,7 +1209,7 @@ static void svm_inject_event(const struct x86_event *event) struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb; eventinj_t eventinj = vmcb->eventinj; struct x86_event _event = *event; - const struct cpu_user_regs *regs = guest_cpu_user_regs(); + struct cpu_user_regs *regs = guest_cpu_user_regs(); switch ( _event.vector ) { @@ -1242,44 +1242,52 @@ static void svm_inject_event(const struct x86_event *event) eventinj.fields.v = 1; eventinj.fields.vector = _event.vector; - /* Refer to AMD Vol 2: System Programming, 15.20 Event Injection. */ + /* + * Refer to AMD Vol 2: System Programming, 15.20 Event Injection. + * + * On hardware lacking NextRIP support, and all hardware in the case of + * icebp, software events with trap semantics need emulating, so %rip in + * the trap frame points after the instruction. + * + * The x86 emulator (if requested by the x86_swint_emulate_* choice) will + * have performed checks such as presence/dpl/etc and believes that the + * event injection will succeed without faulting. + * + * The x86 emulator will always provide fault semantics for software + * events, with _trap.insn_len set appropriately. If the injection + * requires emulation, move %rip forwards at this point. + */ switch ( _event.type ) { case X86_EVENTTYPE_SW_INTERRUPT: /* int $n */ - /* - * Software interrupts (type 4) cannot be properly injected if the - * processor doesn't support NextRIP. Without NextRIP, the emulator - * will have performed DPL and presence checks for us, and will have - * moved eip forward if appropriate. - */ if ( cpu_has_svm_nrips ) - vmcb->nextrip = regs->eip + _event.insn_len; + vmcb->nextrip = regs->rip + _event.insn_len; + else + regs->rip += _event.insn_len; eventinj.fields.type = X86_EVENTTYPE_SW_INTERRUPT; break; case X86_EVENTTYPE_PRI_SW_EXCEPTION: /* icebp */ /* - * icebp's injection must always be emulated. Software injection help - * in x86_emulate has moved eip forward, but NextRIP (if used) still - * needs setting or execution will resume from 0. + * icebp's injection must always be emulated, as hardware does not + * special case HW_EXCEPTION with vector 1 (#DB) as having trap + * semantics. */ + regs->rip += _event.insn_len; if ( cpu_has_svm_nrips ) - vmcb->nextrip = regs->eip; + vmcb->nextrip = regs->rip; eventinj.fields.type = X86_EVENTTYPE_HW_EXCEPTION; break; case X86_EVENTTYPE_SW_EXCEPTION: /* int3, into */ /* - * The AMD manual states that .type=3 (HW exception), .vector=3 or 4, - * will perform DPL checks. Experimentally, DPL and presence checks - * are indeed performed, even without NextRIP support. - * - * However without NextRIP support, the event injection still needs - * fully emulating to get the correct eip in the trap frame, yet get - * the correct faulting eip should a fault occur. + * Hardware special cases HW_EXCEPTION with vectors 3 and 4 as having + * trap semantics, and will perform DPL checks. */ if ( cpu_has_svm_nrips ) - vmcb->nextrip = regs->eip + _event.insn_len; + vmcb->nextrip = regs->rip + _event.insn_len; + else + regs->rip += _event.insn_len; eventinj.fields.type = X86_EVENTTYPE_HW_EXCEPTION; break; @@ -1290,6 +1298,16 @@ static void svm_inject_event(const struct x86_event *event) break; } + /* + * If injecting an event outside of 64bit mode, zero the upper bits of the + * %eip and nextrip after the adjustments above. + */ + if ( !((vmcb->_efer & EFER_LMA) && vmcb->cs.attr.fields.l) ) + { + regs->rip = regs->_eip; + vmcb->nextrip = (uint32_t)vmcb->nextrip; + } + vmcb->eventinj = eventinj; if ( _event.vector == TRAP_page_fault ) diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c index 3e602da..fa8d98f 100644 --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -1694,8 +1694,6 @@ static int inject_swint(enum x86_swint_type type, goto raise_exn; } } - - ctxt->regs->eip += insn_len; } rc = ops->inject_sw_interrupt(type, vector, insn_len, ctxt); diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h b/xen/arch/x86/x86_emulate/x86_emulate.h index 60f9105..f4bcf36 100644 --- a/xen/arch/x86/x86_emulate/x86_emulate.h +++ b/xen/arch/x86/x86_emulate/x86_emulate.h @@ -64,7 +64,13 @@ enum x86_swint_type { x86_swint_int, /* 0xcd $n */ }; -/* How much help is required with software event injection? */ +/* + * How much help is required with software event injection? + * + * All software events return from x86_emulate() with X86EMUL_EXCEPTION and + * fault-like semantics. This just controls whether the emulator performs + * presence/dpl/etc checks and possibly raises exceptions instead. + */ enum x86_swint_emulation { x86_swint_emulate_none, /* Hardware supports all software injection properly */ x86_swint_emulate_icebp,/* Help needed with `icebp` (0xf1) */