From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Tim Deegan <tim@xen.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Jan Beulich <JBeulich@suse.com>
Subject: [PATCH v4 10/24] x86/emul: Always use fault semantics for software events
Date: Thu, 1 Dec 2016 16:55:58 +0000 [thread overview]
Message-ID: <1480611361-15294-3-git-send-email-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <1480611361-15294-1-git-send-email-andrew.cooper3@citrix.com>
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 <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
CC: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
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) */
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-12-01 16:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-01 16:55 [PATCH v4 for-4.9 00/24] [SUBSET] XSA-191 followup Andrew Cooper
2016-12-01 16:55 ` [PATCH v4 09/24] x86/emul: Provide a wrapper to x86_emulate() to ASSERT() certain behaviour Andrew Cooper
2016-12-02 11:26 ` Jan Beulich
2016-12-01 16:55 ` Andrew Cooper [this message]
2016-12-01 19:07 ` [PATCH v4 10/24] x86/emul: Always use fault semantics for software events Boris Ostrovsky
2016-12-02 11:28 ` Jan Beulich
2016-12-01 16:55 ` [PATCH v4 11/24] x86/emul: Implement singlestep as a retire flag Andrew Cooper
2016-12-02 11:32 ` Jan Beulich
2016-12-01 16:56 ` [PATCH v4 17/24] x86/pv: Avoid raising faults behind the emulators back Andrew Cooper
2016-12-01 16:56 ` [PATCH v4 18/24] x86/shadow: " Andrew Cooper
2016-12-02 11:37 ` Jan Beulich
2016-12-02 11:48 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1480611361-15294-3-git-send-email-andrew.cooper3@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).