On Tue, 2019-11-26 at 12:03 +0000, Andrew Cooper wrote: > ICEBP isn't handled well by SVM. > > The VMexit state for a #DB-vectored TASK_SWITCH has %rip pointing to > the > appropriate instruction boundary (fault or trap, as appropriate), > except for > an ICEBP-induced #DB TASK_SWITCH, where %rip points at the ICEBP > instruction > rather than after it. As ICEBP isn't distinguished in the vectoring > event > type, the state is ambiguous. > > To add to the confusion, an ICEBP which occurs due to Introspection > intercepting the instruction, or from x86_emulate() will have %rip > updated as > a consequence of partial emulation required to inject an ICEBP event > in the > first place. > > We could in principle spot the non-injected case in the TASK_SWITCH > handler, > but this still results in complexity if the ICEBP instruction also > has an > Instruction Breakpoint active on it (which genuinely has fault > semantics). > > Unconditionally intercept ICEBP. This does have a trap semantics for > the > intercept, and allows us to move %rip forwards appropriately before > the > TASK_SWITCH intercept is hit. This makes the behaviour of #DB- > vectored > switches consistent however the ICEBP #DB came about, and avoids > special cases > in the TASK_SWITCH intercept. > > This in turn allows for the removal of the conditional > hvm_set_icebp_interception() logic used by the monitor subsystem, as > ICEBP's > will now always be submitted for monitoring checks. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > Reviewed-by: Petre Pircalabu <ppircal...@bitdefender.com>
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
