|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Single step in HVM domU on Intel machine may see wrong DB6
>>> On 07.03.14 at 06:10, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
> How about the following changes: Intercept the TRAP_debug when schedule out
> and drop it after restoring VCPU's DR register into hardware.
Along those lines at least.
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -372,6 +372,10 @@ static void vmx_save_dr(struct vcpu *v)
> v->arch.hvm_vmx.exec_control |= CPU_BASED_MOV_DR_EXITING;
> vmx_update_cpu_exec_control(v);
>
> + /* Trap debug for signle stepping. */
> + v->arch.hvm_vmx.exception_bitmap |= 1 << TRAP_debug;
> + vmx_update_exception_bitmap(v);
> +
> v->arch.debugreg[0] = read_debugreg(0);
> v->arch.debugreg[1] = read_debugreg(1);
> v->arch.debugreg[2] = read_debugreg(2);
> @@ -388,6 +392,13 @@ static void __restore_debug_registers(struct vcpu *v)
>
> v->arch.hvm_vcpu.flag_dr_dirty = 1;
>
> + /*
> + * After restore, hardware has the right context.
> + * So no need to trap debug anymore.
> + */
> + v->arch.hvm_vmx.exception_bitmap |= ~(1 << TRAP_debug);
&=
> + vmx_update_exception_bitmap(v);
> +
> write_debugreg(0, v->arch.debugreg[0]);
> write_debugreg(1, v->arch.debugreg[1]);
> write_debugreg(2, v->arch.debugreg[2]);
> @@ -1171,8 +1182,6 @@ void vmx_update_debug_state(struct vcpu *v)
> unsigned long mask;
>
> mask = 1u << TRAP_int3;
> - if ( !cpu_has_monitor_trap_flag )
> - mask |= 1u << TRAP_debug;
>
> if ( v->arch.hvm_vcpu.debug_state_latch )
> v->arch.hvm_vmx.exception_bitmap |= mask;
If the intercept now really becomes independent of MTF
availability, then I guess this code should be further cleaned up
("mask" becoming pointless as a separate variable).
> @@ -2689,10 +2698,18 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> */
> __vmread(EXIT_QUALIFICATION, &exit_qualification);
> HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
> - write_debugreg(6, exit_qualification | 0xffff0ff0);
> - if ( !v->domain->debugger_attached || cpu_has_monitor_trap_flag )
> - goto exit_and_crash;
> - domain_pause_for_debugger();
> + exit_qualification |= 0xffff0ff0;
Is this really needed?
> + if ( v->domain->debugger_attached )
> + {
> + write_debugreg(6, exit_qualification);
> + domain_pause_for_debugger();
> + }
> + else
> + {
> + __restore_debug_registers(v);
> + write_debugreg(6, exit_qualification | read_debugreg(6));
I still wonder whether it wouldn't be more efficient to simply or
exit_qualification into v->arch.debugreg[6] before calling
__restore_debug_registers().
Jan
> + hvm_inject_hw_exception(TRAP_debug,
> HVM_DELIVER_NO_ERROR_CODE);
> + }
> break;
> case TRAP_int3:
> {
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index dcc3483..0d76d8c 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -378,7 +378,8 @@ static inline int hvm_event_pending(struct vcpu *v)
> (cpu_has_xsave ? X86_CR4_OSXSAVE : 0))))
>
> /* These exceptions must always be intercepted. */
> -#define HVM_TRAP_MASK ((1U << TRAP_machine_check) | (1U << TRAP_invalid_op))
> +#define HVM_TRAP_MASK ((1U << TRAP_machine_check) | (1U << TRAP_invalid_op)
> |\
> + (1U << TRAP_debug))
>
> /*
> * x86 event types. This enumeration is valid for:
>
>
>
> Best regards,
> Yang
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |