This patch addresses an issue where the fast singlestep setting would persist
despite xc_domain_debug_control being called with XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_OFF.
Specifically, if fast singlestep was enabled in a VMI session and that session
stopped before the MTF trap occurred, the fast singlestep setting remained
active even though MTF itself was disabled. This led to a situation where, upon
starting a new VMI session, the first event to trigger an EPT violation would
cause the corresponding EPT event callback to be skipped due to the lingering
fast singlestep setting.
The fix ensures that the fast singlestep setting is properly reset when
disabling single step debugging operations.
Signed-off-by: Petr Beneš <w1benny@gmail.com>
Reviewed-by: Tamas K Lengyel <tamas@tklengyel.com>
master commit:
897def94b56175ce569673a05909d2f223e1e749
master date: 2024-02-12 09:37:58 +0100
int hvm_debug_op(struct vcpu *v, int32_t op)
{
- int rc;
+ int rc = 0;
switch ( op )
{
case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_ON:
case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_OFF:
- rc = -EOPNOTSUPP;
if ( !cpu_has_monitor_trap_flag )
- break;
- rc = 0;
- vcpu_pause(v);
- v->arch.hvm.single_step =
- (op == XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_ON);
- vcpu_unpause(v); /* guest will latch new state */
+ return -EOPNOTSUPP;
break;
default:
- rc = -ENOSYS;
- break;
+ return -ENOSYS;
+ }
+
+ vcpu_pause(v);
+
+ switch ( op )
+ {
+ case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_ON:
+ v->arch.hvm.single_step = true;
+ break;
+
+ case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_OFF:
+ v->arch.hvm.single_step = false;
+ v->arch.hvm.fast_single_step.enabled = false;
+ v->arch.hvm.fast_single_step.p2midx = 0;
+ break;
+
+ default: /* Excluded above */
+ ASSERT_UNREACHABLE();
+ return -ENOSYS;
}
+ vcpu_unpause(v); /* guest will latch new state */
+
return rc;
}