[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 27.02.14 at 02:31, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote: > Jan Beulich wrote on 2014-02-27: >>>>> On 26.02.14 at 06:15, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote: >>> @@ -2690,9 +2688,13 @@ 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(); + if ( >>> v->domain->debugger_attached ) + >>> domain_pause_for_debugger(); + else + { + >>> __restore_debug_registers(v); + >>> hvm_inject_hw_exception(TRAP_debug, HVM_DELIVER_NO_ERROR_CODE); + >>> } >> >> I suppose you need to set DR6.BS after restoring the reigsters? > > Right but is not enough. If flag_dr_dirty is set, we need to restore > register from hardware. Conversely, restore is from debugreg and set DR6 to > exit_qualification. After some more thought, I in fact doubt that restoring the debug registers is in line with the current model: We should simply set DR6.BS in the in-memory copy when the debug registers aren't live yet (and it doesn't hurt to always do that). And since DR6 bits generally are sticky, I think exit_qualification actually needs to be or-ed into the in-memory copy. And presumably we would be better off if we dropped the interception of TRAP_debug once we restored the debug registers. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |